hypervisor: kvm: enable Enlightened VMCS for nested Hyper-V guests

A Windows guest that itself runs Hyper-V (nested Hyper-V, or WSL2 which
is built on it) acts as an L1 hypervisor on top of KVM. On Intel, Hyper-V
does not drive KVM through the architectural VMCS — it uses Microsoft's
Enlightened VMCS (eVMCS) layout, a paravirtualized L0(KVM)<->L1(Hyper-V)
protocol. Cloud Hypervisor never negotiated eVMCS: it enabled only
KVM_CAP_HYPERV_SYNIC and left the Hyper-V nested-features CPUID leaf
(0x4000000A) zeroed. The guest's hvix64 therefore reaches VMXON with no
eVMCS contract in place and the nested launch path stalls.

Wire up the missing piece:

- Add Vcpu::enable_hyperv_enlightened_vmcs(), a no-op by default (so MSHV,
  which handles nesting natively, and non-x86 backends are unaffected) and
  implemented on the KVM backend as KVM_ENABLE_CAP(KVM_CAP_HYPERV_ENLIGHTENED_VMCS).

- In configure_vcpu(), when Hyper-V enlightenments + nested are both on and
  the vCPU is Intel, enable the eVMCS capability before set_cpuid2 (KVM only
  accepts leaf 0x4000000A after the cap is enabled) and then advertise:
    * 0x40000004.EAX bit 14  HV_ENLIGHTENED_VMCS_RECOMMENDED
    * 0x4000000A.EAX low 16  supported eVMCS version range (v1: 0x0101)
                     bit 17  HV_NESTED_DIRECT_FLUSH
                     bit 19  HV_NESTED_MSR_BITMAP

Gated Intel-only because eVMCS is a VMX construct; AMD/SVM is untouched.
Gated on `nested` so non-nested Windows guests are unchanged.

Scope note: this is necessary but, in a deeply-nested environment (e.g. a
cloud instance that is itself an L1 guest, making the Windows guest L2 and
its WSL2/Hyper-V workload L3), may not be sufficient on its own — the host's
own nesting depth can still be the limiting factor. On a bare-metal Intel
KVM host this provides the eVMCS contract Hyper-V requires.

Sources:
  Linux Documentation/virt/kvm/api.rst (KVM_CAP_HYPERV_ENLIGHTENED_VMCS;
    HYPERV_CPUID_NESTED_FEATURES exposed only after the cap is enabled)
  Microsoft Hypervisor Top-Level Functional Specification (eVMCS,
    HV_CPUID_NESTED_FEATURES)
  qemu/qemu docs/system/i386/hyperv.rst (hv-evmcs: Intel-only, nested-only)

Author: CMGS

arch/src/x86_64/mod.rs

@@ -51,6 +51,16 @@ const TSC_DEADLINE_TIMER_ECX_BIT: u8 = 24; // tsc deadline timer ecx bit.
 const HYPERVISOR_ECX_BIT: u8 = 31; // Hypervisor ecx bit.
 const VMX_ECX_BIT: u8 = 5; // VMX for Intel
 const SVM_ECX_BIT: u8 = 2; // SVM for AMD
+
+// Hyper-V Enlightened VMCS, for nested Hyper-V / WSL2 on Intel.
+// Recommended bit in HV_CPUID_ENLIGHTMENT_INFO (0x40000004) EAX.
+const HV_ENLIGHTENED_VMCS_RECOMMENDED_BIT: u32 = 14;
+// HV_CPUID_NESTED_FEATURES (0x4000000A) EAX: low 16 bits encode the supported
+// Enlightened VMCS version range; we report v1 only (low=high=1).
+const HV_ENLIGHTENED_VMCS_VERSION: u32 = 1;
+// HV_CPUID_NESTED_FEATURES (0x4000000A) EAX feature bits.
+const HV_NESTED_DIRECT_FLUSH_BIT: u32 = 17;
+const HV_NESTED_MSR_BITMAP_BIT: u32 = 19;
 const MTRR_EDX_BIT: u8 = 12; // Hypervisor ecx bit.
 const INVARIANT_TSC_EDX_BIT: u8 = 8; // Invariant TSC bit on 0x8000_0007 EDX
 const AMX_BF16: u8 = 22; // AMX tile computation on bfloat16 numbers
@@ -1000,6 +1010,33 @@ pub fn configure_vcpu(
         }
     }
 
+    // Enlightened VMCS lets a Hyper-V guest run as an L1 hypervisor (nested
+    // Hyper-V / WSL2) over KVM. It is Intel-only and only meaningful when both
+    // Hyper-V enlightenments and nested virtualization are enabled. KVM accepts
+    // the Hyper-V nested-features CPUID leaf (0x4000000A) only after the eVMCS
+    // capability has been enabled on the vCPU, so enable it before set_cpuid2.
+    let evmcs = kvm_hyperv && nested && matches!(cpu_vendor, CpuVendor::Intel);
+    if evmcs {
+        vcpu.enable_hyperv_enlightened_vmcs()
+            .map_err(|e| Error::SetSupportedCpusFailed(e.into()))?;
+
+        for entry in &mut cpuid {
+            match entry.function {
+                // HV_CPUID_ENLIGHTMENT_INFO: tell the guest eVMCS is recommended.
+                0x4000_0004 => entry.eax |= 1 << HV_ENLIGHTENED_VMCS_RECOMMENDED_BIT,
+                // HV_CPUID_NESTED_FEATURES: advertise the supported eVMCS version
+                // (low 16 bits) plus the nested enlightenments KVM implements.
+                0x4000_000a => {
+                    entry.eax = HV_ENLIGHTENED_VMCS_VERSION
+                        | (HV_ENLIGHTENED_VMCS_VERSION << 8)
+                        | (1 << HV_NESTED_DIRECT_FLUSH_BIT)
+                        | (1 << HV_NESTED_MSR_BITMAP_BIT);
+                }
+                _ => {}
+            }
+        }
+    }
+
     for c in &cpuid {
         debug!("{c}");
     }

hypervisor/src/cpu.rs

@@ -212,6 +212,10 @@ pub enum HypervisorCpuError {
     ///
     #[error("Failed to enable HyperV SynIC")]
     EnableHyperVSyncIc(#[source] anyhow::Error),
+    /// Enabling HyperV Enlightened VMCS error
+    ///
+    #[error("Failed to enable HyperV Enlightened VMCS")]
+    EnableHyperVEnlightenedVmcs(#[source] anyhow::Error),
     ///
     /// Getting AArch64 core register error
     ///
@@ -417,6 +421,19 @@ pub trait Vcpu: Send + Sync {
     fn enable_hyperv_synic(&self) -> Result<()>;
     #[cfg(target_arch = "x86_64")]
     ///
+    /// X86 specific call to enable HyperV Enlightened VMCS for nested guests.
+    ///
+    /// Enlightened VMCS is the paravirtualized L0<->L1 protocol that a Hyper-V
+    /// guest (acting as an L1 hypervisor, e.g. for WSL2 or nested Hyper-V) uses
+    /// instead of the architectural VMCS layout. It is Intel-only. The default
+    /// implementation is a no-op so backends that do not need it (or handle
+    /// nesting natively, like MSHV) are unaffected.
+    ///
+    fn enable_hyperv_enlightened_vmcs(&self) -> Result<()> {
+        Ok(())
+    }
+    #[cfg(target_arch = "x86_64")]
+    ///
     /// X86 specific call to retrieve the CPUID registers.
     ///
     fn get_cpuid2(&self, num_entries: usize) -> Result<Vec<CpuIdEntry>>;

hypervisor/src/kvm/mod.rs

@@ -68,9 +68,10 @@ use crate::riscv64_reg_id;
 pub mod x86_64;
 #[cfg(target_arch = "x86_64")]
 use kvm_bindings::{
-    KVM_CAP_HYPERV_SYNIC, KVM_CAP_HYPERV_SYNIC2, KVM_CAP_SPLIT_IRQCHIP, KVM_CAP_X2APIC_API,
-    KVM_GUESTDBG_USE_HW_BP, KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK, KVM_X2APIC_API_USE_32BIT_IDS,
-    MsrList, kvm_enable_cap, kvm_msr_entry,
+    KVM_CAP_HYPERV_ENLIGHTENED_VMCS, KVM_CAP_HYPERV_SYNIC, KVM_CAP_HYPERV_SYNIC2,
+    KVM_CAP_SPLIT_IRQCHIP, KVM_CAP_X2APIC_API, KVM_GUESTDBG_USE_HW_BP,
+    KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK, KVM_X2APIC_API_USE_32BIT_IDS, MsrList, kvm_enable_cap,
+    kvm_msr_entry,
 };
 #[cfg(target_arch = "x86_64")]
 use x86_64::check_required_kvm_extensions;
@@ -2247,6 +2248,25 @@ impl cpu::Vcpu for KvmVcpu {
             .map_err(|e| cpu::HypervisorCpuError::EnableHyperVSyncIc(e.into()))
     }
 
+    #[cfg(target_arch = "x86_64")]
+    ///
+    /// X86 specific call to enable HyperV Enlightened VMCS
+    ///
+    fn enable_hyperv_enlightened_vmcs(&self) -> cpu::Result<()> {
+        // A Hyper-V guest acting as an L1 hypervisor (nested Hyper-V / WSL2)
+        // drives KVM through the Enlightened VMCS layout rather than the
+        // architectural VMCS. args[0] receives the eVMCS version supported by
+        // KVM; we don't pin a version here (KVM guarantees at least v1, which
+        // is what the guest negotiates via CPUID 0x4000000A).
+        let cap = kvm_enable_cap {
+            cap: KVM_CAP_HYPERV_ENLIGHTENED_VMCS,
+            ..Default::default()
+        };
+        self.fd
+            .enable_cap(&cap)
+            .map_err(|e| cpu::HypervisorCpuError::EnableHyperVEnlightenedVmcs(e.into()))
+    }
+
     ///
     /// X86 specific call to retrieve the CPUID registers.
     ///