5 Replies Latest reply on Apr 8, 2010 10:12 AM by jmattson

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

    intvsteve Novice

       

      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?