Under whpx, arm reset results in hangs and crashes.

- Arguments out of order in ENCODE_AA64_CP_REG, so get_arm_cp_reginfo()
  fails, whpx_set_registers does nothing for reset, and SCTLR_EL1 retains
  guest state with MMU enabled after reset, resulting in fault and hang.
  Fix via wrapper macro to retain existing ordering convention.
- Fixing the ENCODE_AA64_CP_REG issue results in assertions while trying
  to write to ARM_CP_CONST registers. Skip them.
- Correct four entries in the breakpoint/watchpoint index 1 block that
  named index 0 registers.
- CPUs that are idle at time of reset remain in suspend after reset.
- CPUs are not in the correct StartupSuspend state after reset.

After this change, I am able to repeatedly reset an arm64 guest, using
shutdown-reset, external reset, and watchdog reset.

Doug Cook (3):
  target/arm/whpx: Don't try to sync ARM_CP_CONST registers
  target/arm/whpx: incorrect ENCODE_AA64_CP_REG parameter order
  target/arm/whpx: fix whpx-arm post-reset CPU state

 target/arm/whpx/whpx-all.c | 290 +++++++++++++++++++++----------------
 1 file changed, 162 insertions(+), 128 deletions(-)

-- 
2.55.0.vfs.0.3

On Thu, 20 Aug 2026 at 01:35, Doug Cook (WINDOWS) <dcook@microsoft.com> wrote:
>
> Under whpx, arm reset results in hangs and crashes.
>
> - Arguments out of order in ENCODE_AA64_CP_REG, so get_arm_cp_reginfo()
>   fails, whpx_set_registers does nothing for reset, and SCTLR_EL1 retains
>   guest state with MMU enabled after reset, resulting in fault and hang.
>   Fix via wrapper macro to retain existing ordering convention.
> - Fixing the ENCODE_AA64_CP_REG issue results in assertions while trying
>   to write to ARM_CP_CONST registers. Skip them.
> - Correct four entries in the breakpoint/watchpoint index 1 block that
>   named index 0 registers.
> - CPUs that are idle at time of reset remain in suspend after reset.
> - CPUs are not in the correct StartupSuspend state after reset.
>
> After this change, I am able to repeatedly reset an arm64 guest, using
> shutdown-reset, external reset, and watchdog reset.

Thanks; I've applied this series to target-arm.next.

I noticed that your emails for this don't seem to have been
correctly threaded -- in a patch series, each individual
patch should appear as a reply to the cover letter (i.e with
the usual standard In-Reply-To/References headers). The
patch tooling relies on this to be able to operate on the
patchseries as a unit. In this case since there were only
three patches I was able to manually go and find the emails
and apply them individually, but it gets more awkward the more
patches are involved. If you could have a look at how your
emails are getting sent so that you get the threading right
for future patchsets that would be helpful.

thanks
-- PMM