VMware Communities
mlazovjp
Contributor
Contributor

Forcing guest OS to use x86 when host OS reports x64

I looked through the forums for info on this, but all I saw was something about Solaris 10 (http://communities.vmware.com/message/512286#512286)

My host OS is Vista Business SP1 x64. I have a guest VM running XP Pro SP3.

I am using an AutoIt script to detect the OS and CPU version. It is reporting that the CPU is an x64 architecture,which causes some problems for me since depending on whetherthe VM is reporting an x86 CPU vs an x64 CPU, ti does different things.

Is there any way to force the virutal machine to behave as if it were running an x86 CPU, not an x64 CPU?

Reply
0 Kudos
6 Replies
wila
Immortal
Immortal

Hi,

Is there any way to force the virutal machine to behave as if it were running an x86 CPU, not an x64 CPU?

No you can't do this in VMware Workstation AFAIK as the VM runs directly on the CPU, so the CPU is exposed as it is.

If I'm not mistaken then you could check for environment variables, for example try PROCESSOR_ARCHITECTURE

It shows "x86" here on an x64 capable host (this is under VMware Fusion, but i expect it to be the same) for a 32 bits OS.



--

Wil

_____________________________________________________

Visit the VMware developers wiki at http://www.vi-toolkit.com

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
Reply
0 Kudos
admin
Immortal
Immortal

Add this to your VM configuration file:

monitor_control.disable_longmode = TRUE

Reply
0 Kudos
wila
Immortal
Immortal

Interesting...

Thanks for correcting me 😄

--

Wil

_____________________________________________________

Visit the VMware developers wiki at http://www.vi-toolkit.com

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
Reply
0 Kudos
admin
Immortal
Immortal

You are partially right.

Under software-based virtualization, a user-level CPUID instruction will still report that the CPU supports longmode, since user-level code is run natively in direct execution. However, a kernel-mode CPUID instruction reports whatever we want it to report, since kernel-mode code is subject to binary translation. That's why this works to get Solaris 10 to boot a 32-bit kernel instead of a 64-bit kernel.

Under hardware-assisted virtualization (VT-x or AMD-V), we always intercept the CPUID instruction, regardless of privilege level, and cause it to report whatever we want it to report.

In this particular case, if the guest is running with software-based virtualization, and the application we want to fool runs at user-level, the indicated configuration option will not help.

Reply
0 Kudos
mlazovjp
Contributor
Contributor

Thank you. That may do it ... but we also just discovered that this problem popped up all of a sudden due to some changes in the macros of newer versions of the AutoIt scripting language.

We have since fixed the script to detect properly the version of the OS (32-bit vs 64-bit) instead of relying on the CPU type itself. For those who use AutoIt, we were using the macro @CPUArch (Returns "X86" when the CPU is a 32-bit CPU and "X64" when the CPU is 64-bit.) when we should have been using @OSArch (Returns one of the following: "X86", "IA64", "X64" - this is the architecture

type of the currently running operating system.). The problem showed up when we were running a 32-bit XP VM on an x64 host but our scriptthought that we were running 64-bit XP VM.

Reply
0 Kudos
Stacklake
Contributor
Contributor

monitor_control.disable_longmode

does not work anymore as of 2022.

The only option which seems to work is to use this setting:

 

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

 

Proof: http://techblog.paalijarvi.fi/2022/10/25/forcing-vmware-virtual-machines-to-appear-32-bit-on-64-bit-...

Reply
0 Kudos