Why does vmware workstation mask off the SYSCALL/SYSRET cpuid bit?

[bvickers001]

I'm running VMware workstation 11.1.3 on linux.  In my 64-bit guest operating system, I'm noticing that cpuid for eax=0x8000001 returns an edx value that always masks off bit 11.  This is the SYSCALL/SYSRET capability bit.

Here is the part of the vmware.log file showing my hostCPUID settings:

2016-02-03T15:59:19.629-08:00| vmx| I120: hostCPUID level 80000001, 0: 0x00000000 0x00000000 0x00000021 0x2c100800

As you can see, edx is 0x2c100800, meaning my system is capable of SYSCALL/SYSRET.

I tried adding the following to my vmx file:

monitor_control.enable_fullcpuid = "TRUE"

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

Unfortunately, even with these settings, my vmware log shows no entry in the "CPUID differences from hostCPUID" section for cpuid.80000001.

As a test, I tried modifying bit 10 instead of bit 11 in cpuid.80000001.edx, and that difference showed up.  So what's special about bit 11, and why is it always getting masked inside the VM no matter what I do?

Thanks.

[dariusd]

This:

Unfortunately, even with these settings, my vmware log shows no entry in the "CPUID differences from hostCPUID" section for cpuid.80000001.

suggests that we are passing the SYSCALL capability through to the guest.  If there's no entry for the "differences from hostCPUID", then we should be exposing the same bits to the guest for that leaf as are in the corresponding hostCPUID.

What's the guest OS, and how are you going about checking the CPUID bit inside the VM?  Any chance you could attach the complete vmware.log to your next post?

Cheers,

--

Darius

[admin · Accepted solution]

Are you checking this from 64-bit code or from 32-bit code in compatibility mode?  In 32-bit mode (both legacy and compatibility), only AMD processors set this bit.

[bvickers001]

The guest OS is one I'm writing myself.

It appears that my problem was that Intel processors return different results for CPUID depending on whether you're in 64-bit mode when you call it.

[bvickers001]

Thanks, jmattson.

I'm curious where you found this information (about Intel processors not setting the SYSCALL cpuid bit unless in 64-bit mode).  I cannot find anything about it in the Intel software developers manual, although it's possible I'm looking in the wrong place.

[admin]

I don't believe that Intel documents this behavior anywhere.  It first caused grief for VMware in January 2005, because our software at the time didn't even have the concept of different CPUID results depending on operating mode.

The only other contextual bits I know of are OSXSAVE and OSPKE, which are clearly documented as such.

[Well, okay, there's one more (also undocumented):  a VMware virtual CPU clears CPUID.8000000A.SVM_NPT if CR4.PAE is clear.]