On 11/25/25 6:04 PM, Cornelia Huck wrote:
> 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?
Actually the AArch32 DBGDTRTX is not "hidden" on destination but rather
marked as safe to ignore in the incoming stream (so the other category).
So I don't have any example of TCG usage for this category.
wrt potiential merge I agree they could. 2nd patch is an enforcement of
non access so I prefer to keep them separate but will put them
contiguously in the series.
Eric
>
>> Signed-off-by: Eric Auger <[email protected]>
> Otherwise, LGTM.
>
