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?
