On Mon, 16 Feb 2026 at 03:45, Richard Henderson <[email protected]> wrote: > > RFC mostly because the kernel support is not yet upsteam. > This is based on > > https://lore.kernel.org/linux-arm-kernel/[email protected]/ > > Properly testing this will take more time. I'm not 100% > sure how to confirm that the SME registers have the correct > value across migration. > > I'm thinking of a test case in which the ZArray is loaded, > the test program pauses, migration or vm save/load initiated, > and the ZArray contents are verified after continuing. > But anything that takes timing into account like that > seems way sketchy, so I dunno.
You could avoid the timing dependency by having a test harness that combined QMP and the gdbstub, so that your test program does "set up registers; bkpt; ..." and then you wait for the gdbstub to inform you that the VM has stopped at the breakpoint, before doing a vmsave over QMP. Having to manage two communications channels to the QEMU process might be a bit tedious, though. (We could avoid the two-channels thing by adding a gdbstub QEMU-specific maintenance packet for "execute this monitor command" but unless we think that would be actively helpful for users it seems a bit hacky.) -- PMM
