No; once the extensions have been locked on or locked off by the BIOS, that setting cannot be changed without pulling all power from the CPU.


That's a complicated question. WS may be more fragile than it has to be, but this is a difficult situation. VirtualBox, KVM, and other hypervisors that use VT typically leave the CPU in VMX root operation all of the time. VMX root operation is a crippled operating mode that does not allow the full gamut of normal CPU operations. In particular, you cannot enter real-address mode when in VMX operation.

Why does this matter? Well, when switching between 64-bit mode and legacy 32-bit mode, it is necessary to put the CPU briefly into real-address mode during the switch. If you are running a 64-bit guest on a 32-bit host, this switch is necessary to invoke the 64-bit VMM. Also, for historical reasons, VMware products deal with 64-bit guests using two "peer" VMMs: one in 32-bit legacy mode and one in 64-bit mode. Thus, whether you are running a 64-bit guest on a 32-bit host or on a 64-bit host, you need to switch briefly into real-address mode to invoke the peer that does not match the host in bitness. And, of course, running a 32-bit guest on a 64-bit host, you need to switch briefly into real-address mode to invoke the legacy 32-bit mode VMM.

None of these switches are possible when the system has been put into VMX operation by a foreign hypervisor. Moreover, you cannot even suspend the VM unless you can invoke the VMM. Thus, the only options available are to crash the VM or to busy-wait until the foreign hypervisor goes away.

You may ask why Workstation doesn't simply leave VMX operation, do what is has to do, and then return to VMX operation when it relinquishes the CPU. Unfortunately, Intel's VT design does not make this entirely possible. While it may be possible in some cases, there is the potential of crashing the foreign hypervisor if the foreign hypervisor has active VMs other than its current VM. There is no way in the VT implementation to enumerate all active VMs so that they can be properly shut down when leaving VMX operation and then restarted when resuming VMX operation. Intel apparently did not envision the scenario where there would be multiple hypervisors active on the same CPU.

Thanks for your comments. We are working on improving the user experience.

Still, it would be best for everyone if Virtual Box restored the CPU to normal operation when descheduled.

It would.
It's probably in the hundreds of cycles, at most.
Sorry; I don't know.

I just tried and now it works! (using Player 3.0.0, but I guess it's no difference to Workstation)

Thanks for fixing this and informing about the update.

It's a hack--Intel has assured us that it cannot possibly work.

Unfortunately, I can't say much about our discussions with Intel on this subject. However, one of our assumptions was that we could not necessarily enlist the assistance of other hypervisor vendors to make this work. If the kvm developers are willing to assist us in making this happen, I think we can probably make it happen.

Everything would be fine if all hypervisor vendors could agree to leave VMX operation when yielding the CPU. VMware already does this if the CPU was not in VMX operation when we were scheduled. There may be some resistance to this idea for performance reasons. However, our current hack would be more robust if all hypervisor vendors could agree to clear the "launched" state of every active VMCS on the physical core before yielding the core to us. There may still be some resistance to this idea for performance reasons, but perhaps that's the starting point of a negotiation.

You posted it while I was writting my previous post. You answered many of what I asked before reading my questions ! Do you have anything else to add now that I have described my case in details?