> On 2. Sep 2026, at 23:46, Jiajun Liang <[email protected]> wrote:
>
> Hi Mohamed,
>
> While running an unmodified x86_64 macOS 13 guest on QEMU 11.0.50/WHPX
> (Windows 11, AMD Ryzen 7 9700X), we hit a reproducible shadow page-table
> staleness: after a #PF is delivered and the guest installs the mapping
> (host-side walk shows the PDPTE present, e.g. 0x1f56c6027),
> WHvRunVirtualProcessor keeps faulting on the same address forever. Same-value
> CR3 writes, PCD-toggled CR3 writes, and host-side page-table repair do not
> refresh it. The guest loops 15-20 minutes during early boot (kext-load memcpy
> into freshly mapped kalloc pages).
Hi,
I looked at your #PF trap and re-inject path and unfortunately the cost of
adding a vmexit
on each #PF is way too expensive for general purpose use. It slows down the
hypervisor a lot.
It’d be quite nice if you posted your patches upstream with a DCO if you can
too.
However a side note: was AI assistance involved in generating those patches?
For non-modifiable state, the Hyper-V way to reset it is WHvResetPartition. You
might want to
test it with a single-core VM and syncing back the full state afterwards.
However we don’t have full state sync yet so here be dragons if you tried to
use that…
Also a note that Hyper-V uses EPT, so there’s no shadow page table maintained
for the guest.
>
> Trying WHvDeleteVirtualProcessor + WHvCreateVirtualProcessor (registers
> saved/restored) instead bugchecks the HOST: 0x00020001 HYPERVISOR_ERROR,
> params (0x11, 0x3578c0, 0x1005, 0xffffe70000c04dc0) - reproduced twice,
> minidumps 090326-10984-01.dmp / 090326-9484-01.dmp.
Can you upload those minidumps somewhere? It’s yet another crashing the host
case but that’s never supposed to happen.
>
> Full report: https://gitlab.com/qemu-project/qemu/-/work_items/4385 (notes
> 3778137598 and 3778146512).
>
> Any pointer on how a WHPX consumer is supposed to refresh the shadow after
> guest page-table updates would be much appreciated.
I don’t think there’s such an issue here, but
https://github.com/steelbrain/qemu-reims-vgpu/pull/3/changes/0bc11ef4cadd6c25c4814ea07c594caa1e855170
is definitely intriguing…
> the hypervisor delivers them to the guest only when the guest's fault path is
> mapped
What do you think is actually happening there? I should maybe look a bit more
into macOS
guests, it’s not a scenario I’ve tried.
And which CPU are you testing this on? Does it happen to be an AMD part instead
of Intel?
Things that I’ll take are trapping the CPUID leaf 4 for now.
Thank you,
>
> Thanks!
> Jiajun Liang
