Re: [PATCH v2 20/37] target/arm: Consolidate definitions of PAR

[Peter Maydell <peter.maydell@linaro.org>]

On Tue, 28 Oct 2025 at 15:05, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> On 10/28/25 15:41, Peter Maydell wrote:
> > On Tue, 28 Oct 2025 at 14:39, Richard Henderson
> > <richard.henderson@linaro.org> wrote:
> >>
> >> On 10/20/25 15:31, Peter Maydell wrote:
> >>> On Tue, 14 Oct 2025 at 21:11, Richard Henderson
> >>> <richard.henderson@linaro.org> 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