qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Auger <eric.auger@redhat.com>
To: Cornelia Huck <cohuck@redhat.com>,
	eric.auger.pro@gmail.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 18:35:27 +0100	[thread overview]
Message-ID: <935782b9-27e3-4406-92ec-462413c3ad0b@redhat.com> (raw)
In-Reply-To: <871pluq8u5.fsf@redhat.com>

Hi Connie,

On 11/19/25 5:35 PM, Cornelia Huck wrote:
> 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."
sounds good.

about the TCG index, I am not sure. It rather looks 
cpreg_to_kvm_id(ENCODE_CP_REG()) in the case of Aarch32 DBGDTRTX index I
need to use to succeed the migration



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

Thanks!

Eric
>



  reply	other threads:[~2025-11-19 17: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
2025-11-19 17:35     ` Eric Auger [this message]
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=935782b9-27e3-4406-92ec-462413c3ad0b@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).