From: Eric Auger <eric.auger@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: eric.auger.pro@gmail.com, qemu-devel@nongnu.org,
qemu-arm@nongnu.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 7/7] hw/arm/virt: [DO NOT UPSTREAM] Enforce compatibility with older kernels
Date: Tue, 28 Oct 2025 12:07:15 +0100 [thread overview]
Message-ID: <5909c005-8a7c-4bd9-84c4-e0d6d7009947@redhat.com> (raw)
In-Reply-To: <CAFEAcA_DSo7COpwXF_W4sMiwwmGvZy21GON7UbKWm4H5uDxb4A@mail.gmail.com>
Hi Peter,
On 10/28/25 11:37 AM, Peter Maydell wrote:
> On Thu, 16 Oct 2025 at 15:01, Eric Auger <eric.auger@redhat.com> wrote:
>> This is an example on how to use the new CPU options. This catters to
>> distributions who want machines to be migratable (forward and backward)
>> accross different host kernel versions in case KVM registers exposed
>> to qemu vary accross kernels. This patch is not meant to be upstreamed
>> as it is really kernel dependent. The goal is to illustrate how this
>> would be used.
>>
>> In this example, For 10_1 machines types and older we apply the following
>> host kernel related compats:
>>
>> 1) Make sure the KVM_REG_ARM_VENDOR_HYP_BMAP_2 exposed from v6.15 onwards
>> is ignored/hidden.
>> 2) Make sure TCR_EL1, PIRE0_EL1, PIR_EL1 are always seen by qemu
>> although not exposed by KVM. They were unconditionnally exposed before
>> v6.13 while from v6.13 they are only exposed if supported by the guest.
>>
>> This will allow 10_1 machines types and older machines to migrate
>> forward and backward from old downstream kernels that do not feature
>> those changes to newer kernels (>= v6.15).
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>> ---
>> hw/arm/virt.c | 19 +++++++++++++++++++
>> 1 file changed, 19 insertions(+)
>>
>> diff --git a/hw/arm/virt.c b/hw/arm/virt.c
>> index 175023897a..c4f9b82c38 100644
>> --- a/hw/arm/virt.c
>> +++ b/hw/arm/virt.c
>> @@ -97,6 +97,23 @@ static GlobalProperty arm_virt_compat[] = {
>> };
>> static const size_t arm_virt_compat_len = G_N_ELEMENTS(arm_virt_compat);
>>
>> +/*
>> + * if a 10_1 machine type or older is used:
>> + * 1) make sure TCR_EL1, PIRE0_EL1, PIR_EL1 are enforced, even if they are not
>> + * exposed by the kernel
>> + * 2) hide KVM_REG_ARM_VENDOR_HYP_BMAP_2
>> + */
>> +static GlobalProperty arm_virt_kernel_compat_10_1[] = {
>> + /* KVM_REG_ARM_VENDOR_HYP_BMAP_2 */
>> + { TYPE_ARM_CPU, "kvm-hidden-regs", "0x6030000000160003" },
>> + /* TCR_EL1, PIRE0_EL1, PIR_EL1 */
>> + { TYPE_ARM_CPU, "kvm-enforced-regs",
>> + "0x603000000013c103, 0x603000000013c512, 0x603000000013c513" },
> Strings which are lists of long hex numbers? Is there a
> more readable way to do this?
for sysregs, we could use the reg name string directly once we have
script generated list of regs from json description. However for some
regs it won't be possible, like pseudo FW regs.
As those props are really supposed to be used by very informed users
(distro staff) who need to know the kvm indices, I thought it could be
acceptable. Maybe we can rely on defines to make it more readable.
Thanks
Eric
>
> -- PMM
>
next prev parent reply other threads:[~2025-10-28 11:07 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 [this message]
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=5909c005-8a7c-4bd9-84c4-e0d6d7009947@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).