Hi Peter, On 10/28/25 11:37 AM, Peter Maydell wrote: > On Thu, 16 Oct 2025 at 15:01, Eric Auger <[email protected]> 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 <[email protected]> >> --- >> 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 >
