x86_64: lock IA32_FEATURE_CONTROL with VMXON enabled at boot

[tonicmuroq]

Problem

Windows guests under Cloud Hypervisor cannot run Hyper-V / WSL2 (and therefore Docker Desktop), failing with Virtualization support not detected. Inside the guest:

• VMMonitorModeExtensions = True, SecondLevelAddressTranslation = True (VMX + EPT are exposed in CPUID)
• but VirtualizationFirmwareEnabled = False
• and on enabling Hyper-V, the System log shows Microsoft-Windows-Hyper-V-Hypervisor Event 41: "Hypervisor launch failed; Either VMX not present or not enabled in BIOS."

Root cause

IA32_FEATURE_CONTROL (MSR 0x3A) is owned by firmware. Real BIOS/UEFI locks it at boot with the VMXON-outside-SMX bit set; a guest hypervisor reads it and refuses VMXON if the lock bit is clear. rust-hypervisor-firmware never wrote this MSR, so even though the VMX feature bit is present in CPUID, the guest concludes virtualization is "not enabled in firmware" and nested virt is unusable.

Fix

In rust64_start (x86_64), after paging setup and before handing off to the OS, do what real firmware does: when CPUID reports VMX, lock IA32_FEATURE_CONTROL with VMXON-outside-SMX enabled (0x5).

• Idempotent: skipped if the lock bit is already set.
• Safe on AMD / nested-off: CPUID.1:ECX[5] (VMX) is Intel-specific, so has_vmx is false and the function is a no-op — AMD and non-nested guests are untouched.

Test

Built (x86_64-unknown-none, pinned nightly) and deployed as CLOUDHV.fd to a Cloud Hypervisor host, fresh cold-boot of a Windows 11 guest with the stock cloud-hypervisor binary:

• VirtualizationFirmwareEnabled flips False → True
• the cold boot itself is unaffected (no regression to the boot path)

⚠️ Open issue — end-to-end nested virt is NOT yet confirmed (likely still broken)

This change fixes the firmware-reported state, but it does not yet yield a working nested hypervisor, and may make the failure mode worse.

After the firmware flips VirtualizationFirmwareEnabled to True, I enabled VirtualMachinePlatform + Microsoft-Hyper-V-All and set hypervisorlaunchtype auto, then rebooted the guest. The guest did not come back:

• cloud-hypervisor process stays at ~130–150% CPU (spinning)
• the COW overlay disk is frozen — zero writes for 13+ minutes after the reboot was issued
• cocoon-agent never reconnected

This is the same hang signature as a guest stuck in early boot. The likely reading: with the firmware flag now set, Windows' hvix64 gets past the firmware check (no more Event 41) and proceeds to the actual VMXON, then hangs there — i.e. the underlying nested VMX does not actually function in this host (this is a doubly-nested case: GCE nested-virt L0→L1, Cloud Hypervisor L1→L2 Windows, and Windows Hyper-V would need L2→L3). So this MSR fix appears necessary but not sufficient, and it converts a graceful "not enabled in firmware" failure into a hard hang.

Do not treat this as enabling Docker/WSL2 on Windows guests until the post-VMXON hang is understood. Verification of whether L2→L3 nesting is even supported on the host should land before relying on this.

Targets origin (cocoonstack), not upstream.