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

[Eric Auger <eric.auger@redhat.com>]

Hi Peter,

On 10/28/25 11:47 AM, Peter Maydell wrote:
> 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.

interesting. I will see how this can be extended to TCG
>
> (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 ?

OK I will study that further.

Thank you for your suggestions!

Eric
>
> thanks
> -- PMM
>