From: Cornelia Huck <cohuck@redhat.com>
To: Eric Auger <eric.auger@redhat.com>,
eric.auger.pro@gmail.com, eric.auger@redhat.com,
qemu-devel@nongnu.org, qemu-arm@nongnu.org,
peter.maydell@linaro.org, maz@kernel.org, oliver.upton@linux.dev,
sebott@redhat.com, gshan@redhat.com, ddutile@redhat.com,
peterx@redhat.com, philmd@linaro.org, pbonzini@redhat.com
Subject: Re: [RESEND PATCH 1/7] target/arm/machine: Improve traces on register mismatch during migration
Date: Fri, 17 Oct 2025 16:59:56 +0200 [thread overview]
Message-ID: <877bwtvaj7.fsf@redhat.com> (raw)
In-Reply-To: <20251016140039.250111-2-eric.auger@redhat.com>
On Thu, Oct 16 2025, Eric Auger <eric.auger@redhat.com> wrote:
More information is really valuable here. I have some nits :)
> Currently whenthe number of KVM registers exposed by the source is
s/whenthe/when the/
> 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 patches rework the target/arm/machine code so that it becomes
s/patches rework/patch reworks/
> 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 print but will not fail the migration, as done today.
s/print/printed/
>
> 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 print.
s/print/printed/
If we really get tons of register discrepancies, I'd expect the reason for
that to be something more obvious, so limiting should be fine.
>
> 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
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> ---
> target/arm/cpu.h | 6 +++++
> target/arm/kvm.c | 23 ++++++++++++++++
> target/arm/machine.c | 58 ++++++++++++++++++++++++++++++++++++-----
> target/arm/trace-events | 7 +++++
> 4 files changed, 88 insertions(+), 6 deletions(-)
>
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index bf221e6f97..a7ed3f34f8 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -936,6 +936,12 @@ struct ArchCPU {
> uint64_t *cpreg_vmstate_values;
> int32_t cpreg_vmstate_array_len;
>
> + #define MAX_CPREG_VMSTATE_ANOMALIES 10
> + uint64_t cpreg_vmstate_missing_indexes[MAX_CPREG_VMSTATE_ANOMALIES];
> + int32_t cpreg_vmstate_missing_indexes_array_len;
> + uint64_t cpreg_vmstate_unexpected_indexes[MAX_CPREG_VMSTATE_ANOMALIES];
> + int32_t cpreg_vmstate_unexpected_indexes_array_len;
"indices"?
> +
> DynamicGDBFeatureInfo dyn_sysreg_feature;
> DynamicGDBFeatureInfo dyn_svereg_feature;
> DynamicGDBFeatureInfo dyn_smereg_feature;
(...)
next prev parent reply other threads:[~2025-10-17 15:01 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-16 13:59 [RESEND PATCH 0/7] Mitigation of "failed to load cpu:cpreg_vmstate_array_len" migration failures Eric Auger
2025-10-16 13:59 ` [RESEND PATCH 1/7] target/arm/machine: Improve traces on register mismatch during migration Eric Auger
2025-10-17 14:59 ` Cornelia Huck [this message]
2025-10-28 10:05 ` Eric Auger
2025-11-13 14:35 ` Eric Auger
2025-11-13 14:48 ` Cornelia Huck
2025-11-13 15:01 ` Peter Maydell
2025-11-13 16:11 ` Eric Auger
2025-10-16 13:59 ` [RESEND PATCH 2/7] target/arm/kvm: Introduce the concept of hidden KVM regs Eric Auger
2025-10-16 13:59 ` [RESEND PATCH 3/7] target/arm/kvm: Introduce the concept of enforced/fake registers Eric Auger
2025-10-28 10:35 ` Peter Maydell
2025-10-28 10:58 ` Eric Auger
2025-10-16 13:59 ` [RESEND PATCH 4/7] kvm-all: Add the capability to blacklist some KVM regs Eric Auger
2025-10-16 13:59 ` [RESEND PATCH 5/7] target/arm/cpu: Implement hide_reg callback() Eric Auger
2025-10-16 13:59 ` [RESEND PATCH 6/7] target/arm/kvm: Expose kvm-hidden-regs and kvm-fake-regs properties Eric Auger
2025-10-16 13:59 ` [RESEND PATCH 7/7] hw/arm/virt: [DO NOT UPSTREAM] Enforce compatibility with older kernels Eric Auger
2025-10-28 10:37 ` Peter Maydell
2025-10-28 11:07 ` Eric Auger
2025-10-28 11:09 ` Eric Auger
2025-10-28 10:05 ` [RESEND PATCH 0/7] Mitigation of "failed to load cpu:cpreg_vmstate_array_len" migration failures Eric Auger
2025-10-28 10:47 ` Peter Maydell
2025-10-28 15:27 ` Eric Auger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877bwtvaj7.fsf@redhat.com \
--to=cohuck@redhat.com \
--cc=ddutile@redhat.com \
--cc=eric.auger.pro@gmail.com \
--cc=eric.auger@redhat.com \
--cc=gshan@redhat.com \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=sebott@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.