On Wed, 30 Jul 2025 at 01:32, Fabiano Rosas <faro...@suse.de> wrote:
>
> Fabiano Rosas <faro...@suse.de> writes:
>
> > Fabiano Rosas <faro...@suse.de> writes:
> >
> >> Peter Maydell <peter.mayd...@linaro.org> writes:
> >>> I'm not sure how to handle this, as we have no mechanism for
> >>> "ignore this incoming register value, it is bogus". I'm surprised
> >>> we've never run into this before...
> >>>
> >>
> >> I was thinking the same.
> >>
> >> I actually don't understand what the encoding in cpu->cpreg_indexes is
> >> supposed to represent. How does comparing the indexes implies "in our
> >> list"/"in their list"? Is there some sort of ISA level assumption?
> >>
> >> if (cpu->cpreg_vmstate_indexes[v] > cpu->cpreg_indexes[i]) {
> >> /* register in our list but not incoming : skip it */
> >> continue;
> >> }
> >> if (cpu->cpreg_vmstate_indexes[v] < cpu->cpreg_indexes[i]) {
> >> /* register in their list but not ours: fail migration */
> >> return -1;
> >> }
> >>
> >
> > Ok, I spotted the sorting now.
>
> Turns out the backward migration is also broken because this patch adds
> an extra register:
>
> qemu-system-aarch64: Invalid value 292 expecting positive value <= 291
> qemu-system-aarch64: Failed to load cpu:cpreg_vmstate_array_len
Backward migration is not a design goal for the TCG cpreg machinery:
you will find that we add extra registers from time to time in
over various releases.
> We'll need to develop some proper compat machinery that takes the
> machine version in consideration. For the 10.0 -> 10.1 migration,
> something like (messy code, just a PoC):
For 10.1 I was thinking about just putting back this specific
incorrect register. We can do something a bit cleaner once the
release is out.
thanks
-- PMM
