arch: x86_64: advertise mandatory Hyper-V partition privileges - #8380

Related: #8383 — fixes the same "Windows on the slow clock path" symptom on the vm.restore path (restored TSC page goes stale). This PR is the cold-boot half; both are needed for Windows to use the Hyper-V reference TSC page.

Problem

Windows guests on Cloud Hypervisor (kvm_hyperv=on) never enable the Hyper-V reference TSC page. Although AccessPartitionReferenceTsc (CPUID 0x40000003 EAX bit 9) is advertised, the guest never writes HV_X64_MSR_REFERENCE_TSC (0x40000021). Every QueryPerformanceCounter call falls back to reading HV_X64_MSR_TIME_REF_COUNT (0x40000020) — one VM exit per clock read, millions per second on a busy guest.

Boot-to-steady-state trace of a fresh Windows 11 25H2 guest on stock CH (90 s, kvm:kvm_msr tracepoint):

msr_read  0x40000020  (TIME_REF_COUNT, slow path):   3,249,387
msr_write 0x400000b1  (STIMER0_COUNT):                  75,070
msr_write 0x40000021  (REFERENCE_TSC enable):                0   ← never attempted

Windows happily uses the hypercall page, SynIC, and synthetic timers, but selectively refuses the TSC page. This is the issue anticipated in #4779.

Root cause

The Microsoft "Requirements for Implementing the Microsoft Hypervisor Interface" document marks exactly two partition privileges in CPUID leaf 0x40000003 EAX as "Must be set": AccessHypercallMsrs (bit 5) and AccessVpIndex (bit 6). Cloud Hypervisor advertises neither.

Without bit 5, Windows aborts enlightened-mode initialization before timer-API selection: the kernel's HalpHvTimerApi pointer is left NULL, and KeQueryPerformanceCounter permanently takes the rdmsr 0x40000020 trap path (one VM exit per call) instead of the in-guest TSC-page read (~tens of ns, zero exits).

We confirmed the gate by booting the same Windows image on the same host/kernel under QEMU (-cpu host,hv-time,...): the guest writes 0x40000021 during early boot. Bisecting the full CPUID delta between QEMU's Hyper-V layout and Cloud Hypervisor's (vendor ID string, max leaf, build number, leaves 4–6 contents, EBX privilege bits, frequency-MSR bit, invariant-TSC passthrough) isolated bit 5 as the single load-bearing difference:

Bit 6 is included in this PR because the conformance document mandates both. Every hypervisor on which Windows is known to use the TSC page already sets them: QEMU ORs HV_HYPERCALL_AVAILABLE into leaf 3 unconditionally whenever any hv-* enlightenment is enabled, Propolis's default leaf-3 EAX is VP_INDEX | HYPERCALL ("the minimum set of access rights that all Hyper-V-compatible hypervisors must grant"), and VirtualBox's GIM provider asserts both bits, citing the same Microsoft document.

No backend change is needed: KVM handles the hypercall MSRs (0x40000000/0x40000001) and HV_X64_MSR_VP_INDEX in-kernel unconditionally, and Windows already uses them opportunistically (it writes GUEST_OS_ID/HYPERCALL today despite the missing privilege bit — but its TSC-page init path checks the privilege mask strictly).

Measured effect

All measurements with identical guest images (Windows 10 22H2 / Windows 11 25H2), identical noise suppression inside the guest, settled idle, PowerShell Stopwatch.GetTimestamp() tight-loop (= QPC throughput). Hosts: nested = GCE n2 (Cascade Lake, KVM-on-KVM, kernel 6.8), bare metal = GCE c3-highmem-192-metal (Sapphire Rapids, kernel 6.17).

QPC throughput (calls/sec)

Patched per-call cost lands at or below the PowerShell loop floor (~640–940 ns/iter) — the clock read itself is no longer measurable from the guest. For scale: plain GCE Windows on Google's hypervisor (working TSC page) measures ~944 K calls/sec on the same benchmark; the patched CH guests exceed it.

Host-side VM exits during QPC load (perf kvm stat)

0x40000020 traffic disappears entirely; the boot trace shows the guest writing msr_write 40000021 = 0xd001 (TSC page GPA + enable bit), identical to its behavior under QEMU.

Guest-side idle cost (settled, suppressed)

Win11's high idle interrupt volume partially collapses once the clock path is fast (part of its background activity was induced by the slow clock); Windows 10 22H2 under the patch idles at 413–470 IRQ/s — the quietest configuration we measured anywhere.

Note for users restoring pre-patch snapshots

Snapshots store the vCPU CPUID and restore validates it (CpuidCheckCompatibility), so snapshots taken on a build without these bits will refuse to restore on a build with them (and vice-versa) — same behavior as any CPUID-affecting change. Freshly booted guests are unaffected. Additionally, a Windows guest that booted without the privilege decides against the TSC page once at boot; it must be cold-booted (not restored) under the patched CPUID to pick up the fast path.
Re-tested it, it's okay.

Verification

• tests: fresh Windows 10 22H2 + Windows 11 25H2 boots on nested-KVM and bare-metal hosts, kvm:kvm_msr trace confirms WRMSR 0x40000021 at boot and zero 0x40000020 traffic at steady state.
• Linux guests: unaffected with kvm_hyperv=off (code path not taken). With kvm_hyperv=on, the two added privilege bits correspond to MSRs KVM already implements; this matches what QEMU advertises to every hv-*-enabled guest.