Re: [RESEND PATCH 0/7] Mitigation of "failed to load cpu:cpreg_vmstate_array_len" migration failures

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

On Tue, 28 Oct 2025 at 10:05, Eric Auger <eric.auger@redhat.com> wrote:
>
>
>
> On 10/16/25 3:59 PM, Eric Auger wrote:
> > When migrating ARM guests accross same machines with different host
> > kernels we are likely to encounter failures such as:
> >
> > "failed to load cpu:cpreg_vmstate_array_len"
> >
> > This is due to the fact KVM exposes a different number of registers
> > to qemu on source and destination. When trying to migrate a bigger
> > register set to a smaller one, qemu cannot save the CPU state.
> >
> > For example, recently we faced such kind of situations with:
> > - unconditionnal exposure of KVM_REG_ARM_VENDOR_HYP_BMAP_2 FW pseudo
> >   register from v6.16 onwards. Causes backward migration failure.
> > - removal of unconditionnal exposure of TCR2_EL1, PIRE0_EL1, PIR_EL1
> >   from v6.13 onwards. Causes forward migration failure.

> Gentle ping.
>
> Any comments on the approach?

A couple of general remarks:

(1) This isn't KVM specific -- see e.g. commit 4f2b82f60
where we had to add back a fake cpreg to un-break forward
migration of TCG CPUs. So our handling of this kind of problem
shouldn't be restricted to only working with KVM.

(2) essentially we're re-inventing the migration compat
support that VMStateDescriptions provide. That's kind of
unavoidable because of the way I implemented cpreg migration
years ago, but is there anything we can learn in terms of
(a) required feature set and (b) trying to keep parallels
between the two for the way things work ?

thanks
-- PMM