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
Subject: Re: [RFC 1/3] target/arm/cpu: Add new CPU property for KVM regs to hide
Date: Wed, 08 Oct 2025 15:43:17 +0200 [thread overview]
Message-ID: <87ldllv79m.fsf@redhat.com> (raw)
In-Reply-To: <20250911134324.3702720-2-eric.auger@redhat.com>
On Thu, Sep 11 2025, Eric Auger <eric.auger@redhat.com> wrote:
> New kernels sometimes expose new registers in an unconditionnal
> manner. This situation breaks backward migration as qemu notices
> there are more registers to store on guest than supported in the
> destination kerenl. 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 which features the commit to a destination
> host that doesn't fail.
>
> 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,
> including its state migration.
>
> This patch introduces a CPU property, under the form of an array of
> reg indices which indicates which registers can be ignored.
>
> The goal then is to set this property in machine type compats such
> as:
> static GlobalProperty arm_virt_kernel_compat_10_1[] = {
> /* KVM_REG_ARM_VENDOR_HYP_BMAP_2 */
> { TYPE_ARM_CPU, "kvm-hidden-regs", "0x6030000000160003" },
> }
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> ---
> target/arm/cpu.h | 4 ++++
> target/arm/kvm.c | 36 ++++++++++++++++++++++++++++++++++--
> target/arm/trace-events | 2 ++
> 3 files changed, 40 insertions(+), 2 deletions(-)
>
(...)
> +/**
> + * kvm_vcpu_compat_hidden_reg:
> + * @cpu: ARMCPU
> + * @regidx: index of the register to check
> + *
> + * Depending on the CPU compat returns true if @regidx must be
> + * ignored during sync & migration
Maybe add some more explanation, either here or at the kvm_hidden_regs[]
def? So that people do not need to look at the introducing commit :)
"This is intended for when we know that we do not use the register to be
ignored, and want to keep compatibility."
> + */
> +static inline bool
> +kvm_vcpu_compat_hidden_reg(ARMCPU *cpu, uint64_t regidx)
> +{
> + for (int i = 0; i < cpu->nr_kvm_hidden_regs; i++) {
> + if (cpu->kvm_hidden_regs[i] == regidx) {
> + trace_kvm_vcpu_compat_hidden_reg(regidx);
> + return true;
> + }
> + }
> + return false;
> +}
next prev parent reply other threads:[~2025-10-08 13:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-11 13:40 [RFC 0/3] Mitigation of migration failures accross different host kernels Eric Auger
2025-09-11 13:40 ` [RFC 1/3] target/arm/cpu: Add new CPU property for KVM regs to hide Eric Auger
2025-09-17 14:37 ` Sebastian Ott
2025-09-18 16:16 ` Sebastian Ott
2025-10-03 7:25 ` Eric Auger
2025-10-08 13:49 ` Cornelia Huck
2025-10-14 14:16 ` Eric Auger
2025-10-15 13:12 ` Cornelia Huck
2025-10-16 17:33 ` Eric Auger
2025-10-08 13:43 ` Cornelia Huck [this message]
2025-10-14 13:31 ` Eric Auger
2025-09-11 13:40 ` [RFC 2/3] target/arm/kvm: Add new CPU property for KVM regs to enforce Eric Auger
2025-09-11 13:40 ` [RFC 3/3] hw/arm/virt: [DO NOT UPSTREAM] Enforce compatibility with older kernels Eric Auger
2025-10-03 8:10 ` [RFC 0/3] Mitigation of migration failures accross different host kernels 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=87ldllv79m.fsf@redhat.com \
--to=cohuck@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=peter.maydell@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.