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" },
+};
+static const size_t arm_virt_kernel_compat_10_1_len =
+ G_N_ELEMENTS(arm_virt_kernel_compat_10_1);
+
+
/*
* This cannot be called from the virt_machine_class_init() because
* TYPE_VIRT_MACHINE is abstract and mc->compat_props g_ptr_array_new()
@@ -3539,6 +3556,8 @@ static void virt_machine_10_1_options(MachineClass *mc)
virt_machine_10_2_options(mc);
mc->smbios_memory_device_size = 2047 * TiB;
compat_props_add(mc->compat_props, hw_compat_10_1, hw_compat_10_1_len);
+ compat_props_add(mc->compat_props,
+ arm_virt_kernel_compat_10_1, arm_virt_kernel_compat_10_1_len);
}
DEFINE_VIRT_MACHINE(10, 1)
--
2.49.0On 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?
-- PMM
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?
forgot to mention that we could use x- prefix for those properties to
enphasize they are rather experimental and not meant to be used commonly.
Eric
>
> -- PMM
>
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
>
© 2016 - 2025 Red Hat, Inc.