On Tue, Nov 25 2025, Eric Auger <[email protected]> wrote: > More recent kernels sometimes expose new registers in an > unconditionnal manner. This situation breaks backward migration > as qemu notices there are more registers in the input stream > than supported on the destination host. This leads to a > "failed to load cpu:cpreg_vmstate_array_len" error. > > A good example is the introduction of KVM_REG_ARM_VENDOR_HYP_BMAP_2 > pseudo FW register in v6.16 by commit C0000e58c74e (“KVM: arm64: > Introduce KVM_REG_ARM_VENDOR_HYP_BMAP_2”). Trying to do backward > migration from a host kernel that features the commit to a destination > host that doesn't, fail with above error. > > Currently QEMU is not using that feature so ignoring this latter > is not a problem. An easy way to fix the migration issue is to teach > qemu we don't care about that register and we can simply ignore it > when syncing its state during migration. > > This patch introduces an array of such hidden registers. Soon it will > be settable through an array property. > > If hidden, the register is moved out of the array of cpreg which is > built in kvm_arm_init_cpreg_list(). That way their state won't be > synced.
I'm wondering whether the patch description should also mention non-KVM cases (e.g. the bogus reg that was exposed). It might also make sense to merge patch 5 here? > > Signed-off-by: Eric Auger <[email protected]> Otherwise, LGTM.
