Workaround for VT-x unlock on host resume from sleep/hibernate?

[PeterVB]

Buggy BIOS/UEFI firmware may cause the host VT-x/AMD-V setting to unlock after it resumes from sleep or hibernation. When this happens, 64-bit VirtualBox VMs will refuse to power on, and the VirtualBox Manager will no longer show 64-bit operating systems as choices for new VMs. Host operating systems (e.g. Windows 7 64-bit) seem unaffected by the issue.

When VirtualBox no longer recognizes the host VT-x setting, the only solution is to power off the host completely. For VirtualBox, the only permanent workaround is to disable sleep and/or hibernation. However, other virtualization solutions include built-in solutions to this problem (ref. ​https://communities.vmware.com/docs/DOC-8978).

It would be very helpful if VirtualBox also had a method of automatically re-enabling and re-locking VT-x in this situation. Barring an automatic solution, a global preference to ignore the current VT-x setting might work. (Not sure if VirtualBox is actually reading out the VT-x setting from the BIOS or picking it up from the host?)

I am in the middle of another round of testing regarding this issue and will submit a logfile shortly. Thanks.

[PeterVB]

For what it's worth, I am running Windows 7 SP1 64-bit on a Dell Inspiron 530s with BIOS v1.0.18, using VirtualBox 4.3.4. I am able to demonstrate this problem as follows:

• Logoff Windows and power off the PC
• Power on the PC and boot into Windows
• Logon to Windows, create a Windows 7 64-bit VirtualBox VM
• Boot the VM from a Windows 7 64-bit Setup ISO image, confirm success
• Logoff Windows and reboot the PC
• Logon to Windows, power on the VM and confirm that it still boots Windows Setup
• Logoff Windows and put the PC to sleep (S3) with the power button
• Wake the PC with the mouse and logon to Windows
• Open VirtualBox Manager, create a new VM, note that there are no choices for 64-bit OS
• Power on the original VM and VirtualBox throws this error:

Failed to open a session for the virtual machine Win7x64.

VT-x is disabled in the BIOS. (VERR_VMX_MSR_VMXON_DISABLED).

Result Code: E_FAIL (0x80004005)
Component: Console
Interface: IConsole {8ab7c520-2442-4b66-8d74-4ff1e195d2b6}

I've attached a zip archive with "before" and "after" VBox.log and *.vbox files.

[Mihai Hanor]

After waking up the PC, if you find MSR_IA32_FEATURE_CONTROL (0x3a) bit 0 set, no software can set/reset the register. Bit 0 locks the register. CPU must be powered down to be able to reprogram it. The solution is a new BIOS.

In your particular case, read this and risk it, if you think it's worth it: ​http://board.flatassembler.net/topic.php?t=12230

[Frank Mehnert]

That's correct and therefore I think only a BIOS upgrade can help.

[PeterVB]

@mhanor, thanks for that link. I have very little experience with ASM but I can probably at least follow along. I've already blown the EEPROM on this mobo with a bad flash and since it's soldered on that meant a new board (luckily that was under warranty). Would prefer to avoid further flashing of non-OEM code.

Lobbying Dell to release a fixed BIOS will probably be of no use. This model hasn't seen a new BIOS since February 2009. And I'm fairly confident that other models sold by Dell and various vendors around the same timeframe probably suffer from the same issue. VT-x was probably still too bleeding edge at the time, and I'm sure that vendors were looking at other angles to sell PCs. The "solution" will probably be to buy a new one, though there's nothing wrong at all with this hardware and it's more than capable of running modern Windows or Linux operating systems.

@frank, have you checked the VMware Communities link I included in my original post?

​https://communities.vmware.com/docs/DOC-8978

If the firmware leaves VT unlocked after hibernate and/or sleep, current hosted VMware products will automatically enable and lock VT. A workaround exists for older VMware products. See "Enabling VT-x if Unlocked"

And:

Enabling VT-x if Unlocked

This is already the default behavior for current VMware hosted products (Workstation 7.x, Player 3.x, and Fusion 3.x or newer). For older products, the following workaround may help if your firmware leaves VT-x unlocked, either at power-on, or after hibernate or sleep. Simply add the following option to your system-wide configuration file:

hv.enableIfUnlocked = TRUE

So it seems that VMware has figured out how to workaround this issue? I have a licensed copy of VMware Workstation 7.x that I can install to see how it actually fares in this regard. In the meantime I hope you can consider re-opening the ticket with a view to having a dev take a look at what VMware is doing here. Thanks.

[PeterVB]

Actually, further reading of the VMware article includes this info:

• VT is disabled in the feature control MSR!

If the [VMware bootable diagnostic] ISO also reports that these core(s) leave the feature control MSR unlocked, current VMware hosted products will automatically enable and lock VT. A workaround exists for older VMware products. See "Enabling VT-x if Unlocked," below. However, if the ISO reports that VT is disabled on some core(s) and it does not also report that the feature control MSR is unlocked on these core(s), then it is impossible to enable VT-x through software. [emphasis mine]

mhanor's comments point to the case I've emphasized here. If that is indeed the case with my hardware then it looks like there is no software workaround. I will boot my PC from the VMware bootable diagnostic ISO to see what it says in this regard.

mhanor's link also includes a set of perl scripts to patch Phoenix/Award BIOS that are affected by this issue. If nothing else, my bug post helped lead me to his scripts, and I'm certainly thankful for that.

[PeterVB]

The VMware bootable diagnostic ISO reports "VT is disabled in the feature control MSR!" for both CPUs on my PC (in its current state, with my previously created x64 VM no longer booting). So in my case there's nothing that can be done to make VirtualBox workaround this issue.

Though it's not clear to me if VirtualBox can re-enable and re-lock VT-x if it's currently unlocked. Such a feature would probably be helpful to some VB users. Though mhanor's post on the flatassembler.net forum leads me to believe that "disabled and locked" is a more prevalent bug.

I plan to use mhanor's scripts to patch the BIOS for this model and see if that fixes the problem. Will post the results on this page for posterity's sake.

[PeterVB]

I just finished flashing and testing a Phoenix Award BIOS that has been modified with mhanor's scripts (discussed here: ​http://board.flatassembler.net/topic.php?t=12230). This does indeed solve the problem on my PC (Dell Inspiron 530s). In my case I feel the risk was worth it, but preparing to take the plunge was a real learning curve. I found out that the part labeled "PhoenixBios" on my motherboard was not even the BIOS chip! And because the real BIOS chip is soldered on, there were many considerations to make regarding disaster recovery (should the flashing fail, or the modified BIOS be faulty). I'm familiar with the BIOS flashing process (and using a soldering iron) but this is probably not for everyone. Beware and take care!