On 2/9/26 1:51 PM, Cornelia Huck wrote:
> On Fri, Feb 06 2026, Peter Maydell <[email protected]> wrote:
>
>> On Mon, 26 Jan 2026 at 16:55, Eric Auger <[email protected]> wrote:
>>> Currently when the number of KVM registers exposed by the source is
>>> larger than the one exposed on the destination, the migration fails
>>> with: "failed to load cpu:cpreg_vmstate_array_len"
>>>
>>> This gives no information about which registers are causing the trouble.
>>>
>>> This patch reworks the target/arm/machine code so that it becomes
>>> able to handle an input stream with a larger set of registers than
>>> the destination and print useful information about which registers
>>> are causing the trouble. The migration outcome is unchanged:
>>> - unexpected registers still will fail the migration
>>> - missing ones are printed but will not fail the migration, as done today.
>> Improving the diagnostics here is a great idea.
>>
>>> The input stream can contain MAX_CPREG_VMSTATE_ANOMALIES(10) extra
>>> registers compared to what exists on the target.
>>>
>>> If there are more registers we will still hit the previous
>>> "load cpu:cpreg_vmstate_array_len" error.
>>>
>>> At most, MAX_CPREG_VMSTATE_ANOMALIES missing registers
>>> and MAX_CPREG_VMSTATE_ANOMALIES unexpected registers are printed.
>>>
>>> Example:
>>>
>>> qemu-system-aarch64: kvm_arm_cpu_post_load Missing register in input
>>> stream: 0 0x6030000000160003 fw feat reg 3
>>> qemu-system-aarch64: kvm_arm_cpu_post_load Unexpected register in input
>>> stream: 0 0x603000000013c103 op0:3 op1:0 crn:2 crm:0 op2:3
>>> qemu-system-aarch64: kvm_arm_cpu_post_load Unexpected register in input
>>> stream: 1 0x603000000013c512 op0:3 op1:0 crn:10 crm:2 op2:2
>>> qemu-system-aarch64: kvm_arm_cpu_post_load Unexpected register in input
>>> stream: 2 0x603000000013c513 op0:3 op1:0 crn:10 crm:2 op2:3
>>> qemu-system-aarch64: error while loading state for instance 0x0 of device
>>> 'cpu'
>>> qemu-system-aarch64: load of migration failed: Operation not permitted
>>>
>>> With TCG there is no user friendly formatting of the faulting
>>> register indexes as with KVM. However the 2 added trace points
>>> help to identify the culprit indexes.
>> Could we move kvm_print_register_name() out of kvm.c and into
>> somewhere that the TCG code can use it? (I did think when I
>> was reviewing the patch that added that that we might want it
>> for TCG too eventually.)
> I'm wondering which parts could/should be generalized -- the sysreg
> encodings match with the CP_REG_ encodings, but I don't think much else?
> Might be worth trying to split those regs off?
>
In target/arm/cpregs.h, there is cpreg_to_kvm_id() which is used to
convert some cpreg into kvm regidx.
Those latter are stored in cpu->cpreg_indexes. I noticed that because
when advertising TCG
DBGDTRTX 0x40200000200e0298
as safe to ignore in the incoming stream I used the kvm regidx in the prop
value.
cpreg_to_kvm_id does not use any KVM header. I guess we may rewrite
kvm_print_register_name() into something similar and use it also for TCG. what
do you think?
Thanks
Eric
