On Tue, 28 Oct 2025 at 15:05, Richard Henderson <[email protected]> wrote: > > On 10/28/25 15:41, Peter Maydell wrote: > > On Tue, 28 Oct 2025 at 14:39, Richard Henderson > > <[email protected]> wrote: > >> > >> On 10/20/25 15:31, Peter Maydell wrote: > >>> On Tue, 14 Oct 2025 at 21:11, Richard Henderson > >>> <[email protected]> wrote: > >>>> > >>>> Create a function define_par_register which handles the 3 > >>>> distinct cases for PAR. It is easier to understand with > >>>> the definitions all in one place. > >>>> > >>>> Make the aarch64 to be the primary definition, when present, > >>>> rather than being an alias of the 64-bit non-secure aa32 reg. > >>> > >>> Doesn't that break tcg-to-tcg migration across this commit? > >> > >> I don't know... possibly? > >> I guess we have a test for this somewhere, but it needs setup? > > > > I don't have a test specifically -- I tend to use one > > of my usual lying-around "boot linux" setups that has > > a qcow2 disk file, and then connect the monitor and > > use 'savevm foo' to save, and then check that -loadvm foo > > with the new QEMU works. > > You're right, it doesn't work. It'll make the 128-bit version more > complicated, but I > guess there's no avoiding it.
We in general do not have a good story for handling migration compat for sysregs. See also the "BOGUS_DBGDTR_EL0" sysreg which is an ad-hoc way to deal with "if this is in the incoming data then ignore it", and Eric Auger's series that tries to deal with the KVM situations where the host kernel might remove sysregs and break migration for us. It's possible that there might be some unified way to permit the sysreg migration code to handle "the underlying way we represent the data has changed, we need to fix things up on migration input" so that (like the VMState handling) we have a mechanism for changing the representation the rest of QEMU uses at runtime without breaking compat, keeping the impedance-matching code confined to migration. But that would be a big pile of work, so for the sake of FEAT_SYS128 it's probably better to work around it... thanks -- PMM
