RE: [EXTERNAL] Re: [PATCH] target/i386/whpx: handle processor reset

> > On 18. Aug 2026, at 19:58, Doug Cook (WINDOWS)
> <[email protected]> wrote:
> >
> > WHPX is not properly handling processor reset:
> >
> > - Does not reset partition, so several registers (e.g. Hypercall,
> >  GuestOsId) carry values forward as "Locked" into the next session.
> > - Does not clear hypervisor-managed TSC deadline (live-lock).
> > - Does not re-arm the wait-for-SIPI trigger, so all CPUs start running
> > immediately after reset.
> >
> > Some firmware may tolerate this, but OVMF does not. Typical result is
> > that boot hangs or ends in triple-fault, e.g.
> >
> >  qemu-system-x86_64: WHPX: Unexpected VP exit code 4
> >
> > After this patch, I am able to boot to Windows desktop, reset, and
> > boot back to Windows desktop. Tried many times in sequence with no
> problems.
> > Used several different reset mechanisms (OS shutdown menu, external
> > "reset", watchdog reset) with no problems.
> >
> > Resolves:
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitl
> > ab.com%2Fqemu-project%2Fqemu%2F-
> %2Fwork_items%2F2402&data=05%7C02%7Cdc
> >
> ook%40microsoft.com%7Cebc7a2c3ae3641f12b8308defd533da1%7C72f98
> 8bf86f14
> >
> 1af91ab2d7cd011db47%7C1%7C0%7C639226731139271283%7CUnknow
> n%7CTWFpbGZsb
> >
> 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI
> kFOIjo
> >
> iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TMLja23Uf76wlskB
> p7w%2BiaS
> > x190p%2FQblKks2awOf7C8%3D&reserved=0
> > Signed-off-by: Doug Cook <[email protected]>
> 
> Hi,
> 
> Previous version of this concept at:
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
> hew.org%2FQEMU%2F20260421205749.55060-1-
> mohamed%40unpredictable.fr%2F&data=05%7C02%7Cdcook%40microsoft.
> com%7Cebc7a2c3ae3641f12b8308defd533da1%7C72f988bf86f141af91ab
> 2d7cd011db47%7C1%7C0%7C639226731139298436%7CUnknown%7CTW
> FpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXa
> W4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=tE
> M4SLQ74SCFEwIW1LLW6GM2FGcEmzD5KDMVdo8mr14%3D&reserved=0
> (with it intertwined in a common path for Arm support)
> 
> Using WHvResetPartition as a workaround for some state not being fully
> synchronised isn't ideal though...

As far as I can tell (from testing, not from experience), several important
bits of state (Hypercall, GuestOsId) get "locked" and can only be reset
this way. I would be happy to learn a better way, though.

Thanks!
Doug