CPUID(1) not returning all feature bits on newer Xeon Quad-core CPUs ?

[intvsteve]

I'm using VMWare Player 3.0.1 build-227600 and have noticed the same problem running both Windows xp and RedHat Linux images on a quad-core Xeon. A coworker has seen the same issue using Fusion as well.

On the host OS (Mac / Windows / Linux) I get the following output from CPUID(1):

CPUID(1) : eax=0x000106a5 ebx=0x00100800 ecx=0x009ce3bd edx=0xbfebfbff

Running exactly the same code within a guest OS in VMWare Player:

CPUID(1) : eax=0x000106a5 ebx=0x04100800 ecx=0x00980201 edx=0x0febfbff

Futher code in the library specifically cares about bit 28 in register edx, which is set on processors that support either hyperthreading or multiple cores (and as we know, the new Xeons support both). My VMWare images are configured to run 2 or 4 processors, but CPUID-based identification code does NOT see EDX bit 28 as being set. Intel's sample code for multi-CPU identification assumes this bit will be set as well for CPU topology enumeration. (I'm not going to go into the other differences in ebx, ecx and edx.)

Running the same test code on a Core2 Duo on the host OS produces:

CPUID(1) : eax=0x000006f6 ebx=0x01020800 ecx=0x0000e3bd edx=0xbfebfbff

Running exactly the same code in a guest OS in VMWare player on the Core2 Duo (same VMWare image):

CPUID(1) : eax=0x000006f6 ebx=0x00020800 ecx=0x0000e3bd edx=0xbfebfbff

As far as I can tell, the only variable here is the CPU. The code running directly in a host OS behaves correctly on both the Xeon Quad-core and the Core2 Duo, so the problem seems to be in VMWare Player somewhere.

From what I've seen, there have been numerous Xeon-related issues in VMWare for some time - perhaps this is just another one of them.

Has anyone else seen this and have a reasonable and safe workaround for correctly detecting CPU core / cache topology if VMWare is in the mix?

[admin]

There are some features that the virtual CPU does not support: hyper-threading, VMX, MONITOR/MWAIT, etc. These CPUID feature bits will read as zero in a VM.

[intvsteve]

If that's true, then why does the same version of VMWare Player running the same VMWare image, but on a Core2 Duo, report the HTT bit ? It also reports the HTT bit on an old P4 hyperthreaded, single core processor. It's inconsistent. To be sure, I've only tried this on a handful of different processors (P4 single/dual core, a couple Xeons up to the quad-cores), but so far only the quad core has had the HTT bit missing.

[admin · Accepted solution]

If you run your guest with binary translation, we can't intercept CPUID executed at CPL3, because that code runs in direct execution. Under binary translation, we can only intercept the CPL0 CPUID instructions that we translate. Under hardware-assisted virtualization, we intercept all CPUID instructions, regardless of privilege level. I assume you are issuing CPUID from user code at CPL3. You should be able to play with the preferred execution mode and see the effects of binary translation vs. VT-x.

Under binary translation, if you "disable acceleration," we can intercept all CPUID instructions, since then everything is translated.

[intvsteve]

Ah - yes! Many thanks. It completely slipped my mind that the newest system was the only one w/ hardware virtualization support. Guess I need to polish up my code a little bit.

[admin]

Note that you can use CPUID masking to modify what the virtual machine sees for intercepted CPUID instructions. For example, if you add the following to your configuration file, the guest will see the host's HTT bit:

cpuid.1.edx="---h:----:----:----:----:----:----:----"

Some such changes are relatively benign, while others will cause the guest OS to operate incorrectly.