"whpx: i386: disable TbFlushHypercalls for emulated LAPIC" is a
bugfix, and "target/i386: emulate: include name of unhandled instruction"
is a debugging aid.
"whpx: i386: x2apic emulation" makes things slightly better for Windows
10 users. But I strongly recommend *not* relying on it when possible and
using kernel-irqchip=on instead. On Windows 10 however that's more murky
because PIC interrupt injection is broken (interrupts don't wake the vCPU
from HLT) in that case.
"whpx: i386: wire up feature probing" is yet another commit adding a code path
not used on Windows 10. It'll tell the user today which CPU features they set
are incompatible with the hardware but it does not sync that to the CPUID view
that the guest has.
And then another commit to enable x2apic emulation by default even for
kernel-irqchip=off + re-introducing provided by QEMU enlightenments in a more
functional form to signal that the x2apic can be used. I'm not aware of the
actual vmware freq leaf being used though.
"whpx: x2apic emulation for kernel-irqchip=off follow-up" is rolled into this series.
"whpx: i386: reintroduce enlightenments for Windows 10" is a bugfix to make
x2APIC work as intended on Windows 10 without emulating an IOMMU.
And then at the end but dependent on this series, CPUID intercepts finally...
However that's only supported starting from Windows 11/Server 2022.
Some performance (or lack thereof...) numbers:
On a Ryzen 7 8700GE with a Windows 10 VM running with KVM in nested virt, with
kernel-irqchip=off for the virt Alpine Linux x86_64 ISO (3.23.3) with -smp cores=2,
boot times as reported through dmesg:
- QEMU 10.2: 83 seconds
- QEMU 10.2 with a single core: 18.1 seconds
- as of this series, x2apic forced off: 29 seconds
- as of this series, out of the box: 18 seconds
- and with 1 core instead of two: 12.6 seconds
And with this series on a Windows 11 VM on the same hardware:
- kernel-irqchip=on: 6.5 seconds
- kernel-irqchip=on, x2apic forced off: 7.6 seconds
- kernel-irqchip=off: 8.3 seconds
- hyperv=off,kernel-irqchip=off: 7.6 seconds... which is faster,
so the absence of enlightenment support on Windows 10 doesn't explain things...
With kernel-irqchip=on on Windows 10, when booting with SeaBIOS, it gets stuck in
syslinux due to PIC interrupt injection being broken there. That can be counted
as an infinite boot time (?).
checkpatch false positives:
ERROR: spaces required around that '*' (ctx:WxV)
+ UINT32 Ecx, WHV_CPUID_OUTPUT *CpuidOutput))
Not a multiplication but a pointer reference.
ERROR: space prohibited after that '&' (ctx:ExW)
+ & CPUID_7_0_EDX_CET_IBT) {
^
ERROR: space prohibited after that '&' (ctx:ExW)
+ & CPUID_7_0_ECX_CET_SHSTK) {
^
Because it's multiline.
Changes in v4:
- Ugh for a revision sent quickly, unbreaking the arm64 build...
- and making checkpatch happier to some extent
Changes in v3:
- Fixing CPUID intercepts so that QEMU CPU models work fine now, instead
of the partial intercept that was present in QEMU 10.2
- cleanups
Changes in v2:
- GCC warned when a variable name was re-used within a different (but overlapping)
scope in the same function. It also warned with a -Werror=maybe-uninitialized for
the MSR write case. Address those
- make the in-KVM enlightenments path available on Windows 11 too when -M hyperv=off.
Mohamed Mediouni (7):
target/i386: emulate: include name of unhandled instruction
whpx: i386: x2apic emulation
whpx: i386: wire up feature probing
whpx: i386: disable TbFlushHypercalls for emulated LAPIC
whpx: i386: enable x2apic by default for user-mode LAPIC
whpx: i386: reintroduce enlightenments for Windows 10
whpx: i386: introduce proper cpuid support
accel/whpx/whpx-common.c | 2 +
include/system/whpx-internal.h | 10 ++
target/arm/whpx/whpx-all.c | 1 +
target/i386/cpu.c | 25 +++
target/i386/emulate/x86_emu.c | 4 +-
target/i386/whpx/whpx-all.c | 295 ++++++++++++++++++++++++++++++++-
target/i386/whpx/whpx-i386.h | 4 +
7 files changed, 331 insertions(+), 10 deletions(-)
create mode 100644 target/i386/whpx/whpx-i386.h
--
2.50.1 (Apple Git-155)