Two WHPX capability/property queries were added without a legacy-OS
guard and break "-accel whpx" on Windows 10 (build 17763):
1. WHvCapabilityCodeProcessorFeaturesBanks -> WHV_E_UNKNOWN_CAPABILITY
(hr=0x80370300). whpx_accel_init() aborts with a misleading -ENOSPC
("No space left on device") instead of starting.
2. WHvPartitionPropertyCodeX64MsrExitBitmap -> WHV_E_UNKNOWN_PROPERTY
(hr=0x80370302). Even made non-fatal, leaving x2APIC enabled with no
MSR exits hangs the guest black-screen right after firmware
hand-off, since x2APIC is MSR-based.
Both capabilities are Server 2022 (build 20348)+ only. No shipped
release checked (8.1 through 11.1.1, including git master as of
2026-10-15) has a fix for both at once.
Patch 1 gates the banked capability/property query on
whpx_is_legacy_os(), falling back to the original single-bank
WHvCapabilityCodeProcessorFeatures query -- this restores the
pre-8b87283ce4 behaviour on legacy hosts, same pattern already used for
the perfmon capability in 68438cb3cb.
Patch 2 records whether the MSR exit bitmap property was accepted and,
when it is not, applies x2apic=off so the guest falls back to MMIO
based xAPIC, which is still intercepted without MSR exits.
Verified end-to-end on real hardware (Windows 10 Enterprise LTSC
17763, Intel i7-6700, non-admin build via MSYS2 UCRT64): WHPX
accelerated boot to desktop in ~65s vs. ~600s under TCG, combined with
"-machine q35,pic=off" (a runtime flag, not part of this series) to
route around a separate PIC->APIC handover issue on this OS build.
Akshey Taneja (2):
whpx: i386: do not require ProcessorFeaturesBanks on legacy Windows
whpx: i386: fall back to xAPIC when the MSR exit bitmap is unavailable
target/i386/whpx/whpx-all.c | 94 ++++++++++++++++++++++++++++---------
1 file changed, 73 insertions(+), 21 deletions(-)
--
2.50.1.windows.1
