virtualbox.org

this entry was pulled from a VBox.log running on a Lenova B560 w/ a Pentium P6200 CPU. How is this possible?

00:00:00.945750 CPUM: Matched host CPU INTEL 0x6/0x25/0x5 Intel_Core7_Westmere with CPU DB entry 'Intel Core i7-3960X' (INTEL 0x6/0x2d/0x6 Intel_Core7_SandyBridge).

here is the complete log.

I think the important part of the log is a line above the one you quoted.

HMR3Init: Falling back to raw-mode: VT-x is not available.

From what I can make out in the source code (and I'm no expert so everybody chime in and point out where I'm wrong) when hardware virtualization (VT-x) is not available then it falls back to using software. In that case it seems to need to find the closest match to the actual CPU in a built-in table it uses in order to handle the MSRs in software.

rpmurray wrote:I think the important part of the log is a line above the one you quoted.

HMR3Init: Falling back to raw-mode: VT-x is not available.

From what I can make out in the source code (and I'm no expert so everybody chime in and point out where I'm wrong) when hardware virtualization (VT-x) is not available then it falls back to using software. In that case it seems to need to find the closest match to the actual CPU in a built-in table it uses in order to handle the MSRs in software.

you could be right although I find it odd the closest match to a 2 core Pentium with no VT-x is a quad core i7 with VT-x. I actually created a ticket for it. and I hate doing that.

I forgot to mention the person with this issue couldn't boot a LiveCD in VirtualBox but he could boot his computer with it. He claims he has two other 32bit Linux guests that are fine. I didn't see the logs for those however.

rpmurray wrote:I think the important part of the log is a line above the one you quoted.

HMR3Init: Falling back to raw-mode: VT-x is not available.

From what I can make out in the source code (and I'm no expert so everybody chime in and point out where I'm wrong) when hardware virtualization (VT-x) is not available then it falls back to using software. In that case it seems to need to find the closest match to the actual CPU in a built-in table it uses in order to handle the MSRs in software.

The CPU DB matching is done regardless of hardware virtualization. If you look at the calling code, it's in CPUMR3Init().

You're right regarding its use though; It is mainly done to provide the closest matching MSR behaviour with the physical CPU. Many MSRs are undocumented, behave differently on different CPUs and do other totally weird things. Previous VirtualBox versions simply ignored whatever the guest did with many MSRs (that were deemed unimportant and were are for the most part) in a hope that it didn't change any behavior and more importantly the guest didn't' bother to verify the changes it did. However, this isn't going to work for several corner cases that have been more common in guest OSs today. Since VirtualBox 4.3, CPU matching was implemented with an internal CPU DB database which is a collection of MSR behavior on various physical CPUs and then we mimic the closest matched CPU with fairly accurate behaviour as the physical processors. Of course, there could be a bug in the matching code or typos elsewhere, but that's the primary intention behind the CPU DB.

To be honest I'm sorry I got involved trying to help the person who claimed to be having a problem from another forum. I started thinking after trying to deal with him for awhile that he was just trying to waste people's time who were involved with the particular Linux OS. Thanks for the replies though.