There are sometimes needs to run 32-bit VMware guest images on a 64-bit host. This is possible, for example in VMware Workstation 15 Player. The out-of-the-box behavior, however, is that the Player passes trough the CPU information more or less as such. The result is that the guest sees a x86_64 processor, not a x86 processor. Frequently this detection is made by reading the CPUID 29th feature bit for so-called “long mode” (see: https://en.wikipedia.org/wiki/CPUID#EAX=80000001h:_Extended_Processor_Info_and_Feature_Bits ). As this is seen by the guest, it might think it needs to run 64-bit image (Player does not force this, it is a decision of the image itself). The long mode bit seen from Linux /proc/cpuinfo :
There are a lot of posts on vmware.com asking about how to force their 64-bit host to run 32-bit images. One such is here: https://communities.vmware.com/t5/VMware-Workstation-Pro/Forcing-guest-OS-to-use-x86-when-host-OS-reports-x64/td-p/677324 . The advice seems to always be this setting to the .vmx file:
monitor_control.disable_longmode = 1
Even the official VMware answer is the same.
Lets take a look at the log and see what happens with this setting:
2022-10-25T01:14:57.237+03:00| vmx| I005: [msg.monitorcontrol.unrecognized.config.name] The configuration file “C:\VMWARE\VMS\Bios32OtherTest\Bios32OtherTest.vmx” contains an unrecognized monitor control: “monitor_control.disable_longmode”
So the problem is this option is TOTALLY WRONG. At least in year 2022. There is a solution though.
If we do an educated guess and put something on paper…
we come to the conclusion that the following setup to the .vmx file forces the CPUID 29th bit to zero, effectively making the system to appear (more) truly 32-bit to the image running!
The setting is here:
cpuid.80000001.edx = "--0-:----:----:----:----:----:----:----"
And to finally confirm it, lets take a look at /proc/cpuid again after incorporating the setting to .vmx file:
As we can see, lm bit is gone and the image is now (more) truly 32-bit and passes more in-software tests for it. For me knowing the bit-width is extremely important in my iPXE setup, as I present different configuration files (32-bit vs 64-bit) based on the lm bit.