qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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: [PATCH v2 2/8] target/arm/cpu: Allow registers to be hidden
Date: Wed, 19 Nov 2025 17:35:14 +0100	[thread overview]
Message-ID: <871pluq8u5.fsf@redhat.com> (raw)
In-Reply-To: <20251118160920.554809-3-eric.auger@redhat.com>

On Tue, Nov 18 2025, Eric Auger <eric.auger@redhat.com> 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.
>
> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>
> ---
>
> v1 -> v2:
> - Move the property in a separate patch
> - improve the commit msg
> - change the trace point to just print info in
>   kvm_arm_init_cpreg_list()
> - improve comment in cpu.h (Connie)
> ---
>  target/arm/cpu.h        | 23 +++++++++++++++++++++++
>  target/arm/kvm.c        | 12 +++++++++++-
>  target/arm/trace-events |  2 ++
>  3 files changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index 077b0cce5b..0a283940be 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -1044,6 +1044,18 @@ struct ArchCPU {
>      /* KVM steal time */
>      OnOffAuto kvm_steal_time;
>  
> +    /*
> +     * Register indexes that must be hidden. Although normally
> +     * supported (defined in TCG description or exposed by KVM) they are
> +     * willingly hidden for migration sake. This may be used to allow
> +     * backward migration to older versions that do implement a specific
> +     * feature. With KVM acceleration the indexes are the ones described
> +     * in linux/Documentation/virt/kvm/api.rst. With TCG, this is the TCG
> +     * sysreg index.
> +     */

Hmm... what about

"Array of register indexes that need to be hidden to allow migration in
certain cases, i.e. when a register is exposed in KVM or defined in TCG
but not actually used in QEMU. For the KVM case, the indexes are as
described in Linux Documentation/virt/kvm/api.rst. For TCG, the indexes
are the TCG sysreg indexes."

> +    uint64_t *hidden_regs;
> +    uint32_t nr_hidden_regs;
> +
>      /* Uniprocessor system with MP extensions */
>      bool mp_is_up;
>  

Otherwise, LGTM.



  reply	other threads:[~2025-11-19 16:35 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-18 16:07 [PATCH v2 0/8] Mitigation of "failed to load cpu:cpreg_vmstate_array_len" migration failures Eric Auger
2025-11-18 16:07 ` [PATCH v2 1/8] target/arm/machine: Improve traces on register mismatch during migration Eric Auger
2025-11-19 14:51   ` Cornelia Huck
2025-11-18 16:07 ` [PATCH v2 2/8] target/arm/cpu: Allow registers to be hidden Eric Auger
2025-11-19 16:35   ` Cornelia Huck [this message]
2025-11-19 17:35     ` Eric Auger
2025-11-18 16:07 ` [PATCH v2 3/8] target/arm/machine: Allow extra regs in the incoming stream Eric Auger
2025-11-18 16:07 ` [PATCH v2 4/8] target/arm/helper: Skip hidden registers Eric Auger
2025-11-19  8:32   ` Eric Auger
2025-11-18 16:07 ` [PATCH v2 5/8] kvm-all: Add the capability to blacklist some KVM regs Eric Auger
2025-11-18 16:07 ` [PATCH v2 6/8] target/arm/cpu: Implement hide_reg callback() Eric Auger
2025-11-18 16:07 ` [PATCH v2 7/8] target/arm/cpu: Expose x-mig-hidden-regs and x-mig-safe-missing-regs properties Eric Auger
2025-11-18 16:07 ` [PATCH v2 8/8] hw/arm/virt: [DO NOT UPSTREAM] Enforce compatibility with older 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=871pluq8u5.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).