From 89c868408a2b71f838c6964d4461c480a108d0e7 Mon Sep 17 00:00:00 2001
From: Jiajun Liang <3138947285@qq.com>
Date: Mon, 31 Aug 2026 18:44:42 +0800
Subject: [PATCH] whpx: intercept CPUID leaf 4 so guests get the host cache
 topology

The hypervisor answered CPUID leaf 4 (deterministic cache parameters)
itself because leaf 4 was not in the partition's CPUID exit list. Its
answer degenerates on this setup: the first subleaf reports cache type 0
(no more caches), so a guest deriving its core count from
leaf4.EAX[31:26]+1 falls back to 1 core per package while leaf 1 still
reports 16 logical processors. XNU then computes
nPThreadsPerCore = 16 / 1 and divides by zero downstream in
cpu_thread_alloc during smp_init (kernel panic, divide error).

Add leaf 4 to the CPUID exit list so QEMU's cpu_x86_cpuid answers it
with the configured cache topology instead.

Contract: Intel SDM Vol.2 CPUID leaf 4 defines EAX[31:26] as the
maximum number of addressable IDs for logical processors sharing this
cache; QEMU builds that from env->cache_info.

Verified on the x86 macOS / WHPX pathway (Windows 11 host): the guest
now queries leaf 4 (previously it never reached QEMU), cores per package
is derived as 16, the divide error disappears, and the guest advances
past smp_init through VM bootstrap, scheduler init, and Mach object
setup.

Signed-off-by: Jiajun Liang <3138947285@qq.com>
---
 target/i386/whpx/whpx-all.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/i386/whpx/whpx-all.c b/target/i386/whpx/whpx-all.c
index 113f79a..a9e74c9 100644
--- a/target/i386/whpx/whpx-all.c
+++ b/target/i386/whpx/whpx-all.c
@@ -3039,7 +3039,7 @@ int whpx_accel_init(AccelState *as, MachineState *ms)
     WHV_PROCESSOR_FEATURES_BANKS processor_features;
     WHV_PROCESSOR_PERFMON_FEATURES perfmon_features;
 
-    UINT32 cpuidExitList[] = {0x0, 0x1, 0x6, 0x7, 0xb, 0xd, 0x14, 0x24, 0x29, 0x1E,
+    UINT32 cpuidExitList[] = {0x0, 0x1, 0x4, 0x6, 0x7, 0xb, 0xd, 0x14, 0x24, 0x29, 0x1E,
         0x40000000, 0x40000001, 0x40000010, 0x80000000, 0x80000001,
         0x80000002, 0x80000003, 0x80000004, 0x80000007, 0x80000008,
         0x8000000A, 0x80000021, 0x80000022, 0xC0000000, 0xC0000001};
-- 
2.55.0

Hi,

Gentle ping on this patch (CPUID leaf 4 trap for WHPX). It is still on
patchew awaiting review; is there anything I can do to move it forward
(rebase, commit message, or splitting the six-fix series)?

While debugging further on the same Windows/AMD host I isolated two
more WHPX defects that look worth sending as follow-up patches, both of
which reproduce guest-visible corruption:

1. Stale XSAVE image written back into Hyper-V. On this host
   WHvGetVirtualProcessorState(Xsave) fails on every call, so QEMU's
   env FP/SSE/AVX image is never refreshed; any vm_stop/vm_start cycle
   (gdb attach, QMP stop, migration pause) then writes the stale image
   back and clobbers live vector registers on all VPs, corrupting the
   guest. Proposed fix: track xsave validity per VP and skip the
   write-back when the read never succeeded.

2. MemoryAccess MMIO dispatch runs without the BQL. whpx_vcpu_run
   drops the BQL before WHvRunVirtualProcessor and the MemoryAccess
   exit path never reacquires it, so device MMIO handlers run BQL-free
   on vCPU threads (KVM/TCG/HVF all dispatch MMIO under the BQL).
   Devices touching MemoryRegion state race the main loop. Proposed
   fix: take the BQL around emulate_instruction in whpx_handle_mmio.

I can post both as proper patches if they are not already known /
in flight. Happy to follow the project's AI-contribution policy
statement as discussed.

Thanks,
Jiajun Liang