On 09/01/26 6:05 pm, Fabiano Rosas wrote:
The commit referenced (from QEMU 10.0) has changed the way the pseries machine marks a cpu as quiesced. Previously, the cpu->halted value from QEMU common cpu code was (incorrectly) used. With the fix, the env->quiesced variable starts being used, which improves on the original situation, but also causes a side effect after migration: The env->quiesced is set at reset and never migrated, which causes the destination QEMU to stop delivering interrupts and hang the machine. To fix the issue from this point on, start migrating the env->quiesced value. For QEMU versions < 10.0, sending the new element on the stream would cause migration to be aborted, so add the appropriate compatibility property to omit the new subsection. Independently of this patch, all migrations from QEMU versions < 10.0 would result in a hang since the older QEMU never migrates env->quiesced. This is bad because it leaves machines already running on the old QEMU without a migration path into newer versions. As a workaround, use a few heuristics to infer the new value of env->quiesced based on cpu->halted, LPCR and PSSCR bits that are usually set/cleared along with quiesced. Note that this was tested with -cpu power9 and -machine ic-mode=xive due to another bug affecting migration of XICS guests. Tested both forward and backward migration and savevm/loadvm from 9.2 and 10.0. Also tested loadvm of a savevm image that contains a mix of cpus both halted and not halted. Reported-by: Fabian Vogt<[email protected]> Resolves:https://gitlab.com/qemu-project/qemu/-/issues/3079 Fixes: fb802acdc8b ("ppc/spapr: Fix RTAS stopped state") Signed-off-by: Fabiano Rosas<[email protected]>
Reviewed-by: Harsh Prateek Bora <[email protected]> and Queued.
