qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Auger <eric.auger@redhat.com>
To: eric.auger.pro@gmail.com, qemu-devel@nongnu.org,
	qemu-arm@nongnu.org, peter.maydell@linaro.org, cohuck@redhat.com,
	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 0/7] Mitigation of "failed to load cpu:cpreg_vmstate_array_len" migration failures
Date: Tue, 28 Oct 2025 11:05:52 +0100	[thread overview]
Message-ID: <3c963761-8587-4905-8c8b-60dda381262f@redhat.com> (raw)
In-Reply-To: <20251016140039.250111-1-eric.auger@redhat.com>



On 10/16/25 3:59 PM, Eric Auger wrote:
> When migrating ARM guests accross same machines with different host
> kernels we are likely to encounter failures such as:
>
> "failed to load cpu:cpreg_vmstate_array_len"
>
> This is due to the fact KVM exposes a different number of registers
> to qemu on source and destination. When trying to migrate a bigger
> register set to a smaller one, qemu cannot save the CPU state.
>
> For example, recently we faced such kind of situations with:
> - unconditionnal exposure of KVM_REG_ARM_VENDOR_HYP_BMAP_2 FW pseudo
>   register from v6.16 onwards. Causes backward migration failure.
> - removal of unconditionnal exposure of TCR2_EL1, PIRE0_EL1, PIR_EL1
>   from v6.13 onwards. Causes forward migration failure.
>
> This situation is really problematic for distributions which want to
> guarantee forward and backward migration of a given machine type
> between different releases.
>
> This small series tries to address that issue by introducing CPU
> array properties that list the registers to ignore or to fake according
> to the situation. An example is given to illustrate how those props
> could be used to apply compats for machine types supposed to "see" the
> same register set accross various host kernels.
>
> The first patch improves the tracing so that we can quickly detect
> which registers are unexpected and cause the migration failure. Missing
> registers are also traced. Those do not fail migration but their default
> value is kept on the destination.
>
> Then we introduce the infrastructure to handle 'hidden' registers and
> 'fake' registers.
>
> Eric Auger (7):
>   target/arm/machine: Improve traces on register mismatch during
>     migration
>   target/arm/kvm: Introduce the concept of hidden KVM regs
>   target/arm/kvm: Introduce the concept of enforced/fake registers
>   kvm-all: Add the capability to blacklist some KVM regs
>   target/arm/cpu: Implement hide_reg callback()
>   target/arm/kvm: Expose kvm-hidden-regs and kvm-fake-regs properties
>   hw/arm/virt: [DO NOT UPSTREAM] Enforce compatibility with older
>     kernels

Gentle ping.

Any comments on the approach?

Thanks

Eric
>
>  include/hw/core/cpu.h   |  2 ++
>  target/arm/cpu.h        | 42 ++++++++++++++++++++++++
>  accel/kvm/kvm-all.c     | 12 +++++++
>  hw/arm/virt.c           | 19 +++++++++++
>  target/arm/cpu.c        | 12 +++++++
>  target/arm/kvm.c        | 73 ++++++++++++++++++++++++++++++++++++++++-
>  target/arm/machine.c    | 71 +++++++++++++++++++++++++++++++++++----
>  target/arm/trace-events | 11 +++++++
>  8 files changed, 235 insertions(+), 7 deletions(-)
>



  parent reply	other threads:[~2025-10-28 10:06 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
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 ` Eric Auger [this message]
2025-10-28 10:47   ` [RESEND PATCH 0/7] Mitigation of "failed to load cpu:cpreg_vmstate_array_len" migration failures 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=3c963761-8587-4905-8c8b-60dda381262f@redhat.com \
    --to=eric.auger@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=ddutile@redhat.com \
    --cc=eric.auger.pro@gmail.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).