On Tue, 28 Oct 2025 at 10:05, Eric Auger <[email protected]> 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
