Peter Maydell <peter.mayd...@linaro.org> writes:
> 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.
>
Ok, I'll document this once we fix the compatibility tests for
aarch64. Only test in one direction.
>> 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.
>
Your call. I've put an RFC out, but it also requires re-work after
release.
> thanks
> -- PMM
