[v6] kvm/arm: Introduce a customizable aarch64 KVM host model

[RFC PATCH v6 00/17] kvm/arm: Introduce a customizable aarch64 KVM host model

Posted by Eric Auger 2 days ago

This series enhances the current host KVM model with capability to
set writable ID reg fields. 

Since v6.7 kernel, KVM/arm allows the userspace to overwrite the values
of a subset of ID regs. The list of writable fields continues to grow.
The feature ID range is defined as the AArch64 System register space
with op0==3, op1=={0, 1, 3}, CRn==0, CRm=={0-7}, op2=={0-7}.

The end goal is to get more flexibility when migrating guests
between different host hardware.

QEMU retrieves the writable ID fields from KVM UAPI [1] and
match them against a generated description of ID regs and their
named fields that stem from AARCHMRS Registers.json file.
Current description is based on latest 2026-03 edition.
The content of the generated files was compared against kernel
linux/arch/arm64/tools/sysreg file. It is not straightforward
to have unit tests for python scripts as there are many cases for
field extraction.

For each writable named field a uint64 property is created
following the "SYSREG_<REG>_<FIELD>" naming convention. REG and
FIELD names are those described in ARM ARM Reference manual.

The list of SYSREG_ID properties can be retrieved through the qmp
monitor using query-cpu-model-expansion [2].

For the record, Jinqian was able to migrate between Hisilicon KunPeng
HIP09 and HIP12 chips with this series using this kind of command:

-cpu host,pauth=off,pmu=off,sve=off,\
SYSREG_ID_AA64PFR1_EL1_NMI=0x0,\
SYSREG_ID_AA64ISAR1_EL1_LS64=0x0,\
SYSREG_ID_AA64ISAR1_EL1_XS=0x0,\
SYSREG_ID_AA64ISAR1_EL1_LRCPC=0x2,\
SYSREG_ID_AA64ISAR2_EL1_RPRFM=0x0,\
SYSREG_ID_AA64ISAR2_EL1_CLRBHB=0x0,\
SYSREG_ID_AA64ISAR2_EL1_PAC_frac=0x0,\
SYSREG_ID_AA64ISAR2_EL1_BC=0x0,\
SYSREG_ID_AA64ISAR2_EL1_RPRES=0x0,\
SYSREG_ID_AA64ISAR2_EL1_WFxT=0x0,\
SYSREG_ID_AA64MMFR0_EL1_FGT=0x0,\
SYSREG_ID_AA64MMFR0_EL1_BigEnd=0x0,\
SYSREG_ID_AA64MMFR1_EL1_ECBHB=0x0,\
SYSREG_ID_AA64MMFR1_EL1_CMOW=0x0,\
SYSREG_ID_AA64MMFR1_EL1_TIDCP1=0x0,\
SYSREG_ID_AA64MMFR1_EL1_nTLBPA=0x0,\
SYSREG_ID_AA64MMFR1_EL1_AFP=0x0,\
SYSREG_ID_AA64MMFR1_EL1_HCX=0x0,\
SYSREG_ID_AA64MMFR1_EL1_ETS=0x0,\
SYSREG_ID_AA64MMFR1_EL1_PAN=0x2,\
SYSREG_ID_AA64MMFR1_EL1_HAFDBS=0x2,\
SYSREG_ID_AA64MMFR2_EL1_CnP=0x0,\
SYSREG_ID_AA64MMFR3_EL1_TCRX=0x0,\
SYSREG_ID_AA64DFR0_EL1_PMUVer=0x6,\
SYSREG_ID_AA64DFR0_EL1_DebugVer=0x9,\
SYSREG_ID_AA64DFR0_EL1_DoubleLock=0xf,\
SYSREG_ID_AA64ZFR0_EL1_F64MM=0x0,\
SYSREG_ID_AA64ZFR0_EL1_F32MM=0x0,\
SYSREG_ID_AA64ZFR0_EL1_SM4=0x0,\
SYSREG_ID_AA64ZFR0_EL1_SHA3=0x0,\
SYSREG_ID_AA64ZFR0_EL1_BitPerm=0x0,\
SYSREG_ID_AA64ZFR0_EL1_AES=0x0,\
SYSREG_ID_AA64ZFR0_EL1_SVEver=0x0,\
SYSREG_CTR_EL0_L1Ip=0x2 \

Connie & Eric

This series can be found at:
https://github.com/eauger/qemu/tree/arm-cpu-model-v6

History:
--------
v5 -> v6:
v6 is mostly for Khushit to see how he may work on top
of this series. It fulfills some of his requirements:
- Upon Khushit request I added description for enum values
  and reserved fields
- set_sysreg_prop checks the input value against enum values
  if any
- writable_bitmap is now dispatched into the sysreg descripton
  and not stored in vcpu state anymore (besides it is VM wide)
- implemented write for qmp inspection. However this is not
  yet checked against KVM. That's the next step I think, ie.
  instantiate a scratch vcpu to test if the field value can be
  applied?
- if some inconsistencies between writable mask and idreg
  field, reserved fields only produce traces
- simplify checks related to availability of writable map
- this version does not yet fix some reported issues about host
  supporting nested virt. I will further sync with Khushit.
  so this is definitively not candidate to be applied, hence the
  RFC tag.

v4 -> v5:
- generate target/arm/cpu-idregs.h.inc that look similar to
  the format used in [RFC PATCH v1 02/13] target/arm:
  named_cpu_model: Add ID Register Fields without the
  description of the value values nor safe policy/value.
  I guess valid values could be generated from the Registers.json
  file too. Safe policy/values cannot.
  I reused one patch from the above series.
  Let's see how both series can progress/coexist without any
  anticipated bias.
- Addressed all comments from Shameer on v4
- Addressed 2 comments from v4 that were missed including the
  issue of IDreg visibility affected by some other settings.
  Unfortunately I was not able to test it.
- Further look at overrides between low level id reg field
  properties versus legacy CPU options. I have the feeling they
  can coexist as long as we document the hierarchy between them:
  host kvm default -> ID reg field props -> legacy CPU options
- Noticed more writable fields that are RES0/RAZ
- Improved commit messages in general

References:
-----------

[1]
KVM_CAP_ARM_SUPPORTED_REG_MASK_RANGES
KVM_ARM_GET_REG_WRITABLE_MASKS
Documentation/virt/kvm/api.rst

[2]
qemu-system-aarch64 -qmp unix:/home/augere/TEST/QEMU/qmp-sock,server,nowait -M virt --enable-kvm -cpu host
sudo build/run qmp-shell /home/augere/TEST/QEMU/qmp-sock
Welcome to the QMP low-level shell!
Connected to QEMU 11.0.50
(QEMU) query-cpu-model-expansion type=full model={"name":"host"}


Cornelia Huck (3):
  target/arm/kvm: Retrieve writable ID reg map
  arm-qmp-cmds: introspection for ID register props
  arm/cpu-features: document ID reg properties

Eric Auger (13):
  scripts: introduce scripts/update-aarch64-cpu-sysregs-header.py
  target/arm/cpu-sysregs.h.inc: Sort by name alphabetical order
  target/arm/cpu-sysregs.h.inc: Update with automatic generation
  arm/cpu: Add infra to handle generated ID register definitions
  scripts: Introduce scripts/aarch64_sysreg_helpers module
  scripts: Introduce scripts/update-aarch64-cpu-sysreg-properties.py
  target/arm/cpu-idregs.h.inc: generate with script
  target/arm/cpu-idregs.h.inc: Generate enum values
  arm/kvm: Initialize all writable ID registers from host
  target/arm/kvm: Introduce kvm_arm_expose_idreg_properties
  target/arm/cpu: Expose writable ID reg field properties on the kvm
    host vcpu model
  target/arm/cpu-idregs.h.inc: Generate reserved fields
  target/arm/kvm: Ignore and trace unexpected writable reserved fields

Shaju Abraham (1):
  target/arm/cpu_idregs: generate tables for Arm64 ID registers and
    fields

 docs/system/arm/cpu-features.rst              |  106 +-
 target/arm/cpu-idregs.h                       |   41 +
 target/arm/kvm_arm.h                          |   10 +
 target/arm/cpu-idregs.h.inc                   | 2164 +++++++++++++++++
 target/arm/cpu-sysregs.h.inc                  |   57 +-
 target/arm/arm-qmp-cmds.c                     |   29 +
 target/arm/cpu-idregs.c                       |   96 +
 target/arm/cpu64.c                            |    5 +
 target/arm/kvm.c                              |  311 ++-
 scripts/aarch64_sysreg_helpers.py             |  109 +
 .../update-aarch64-cpu-sysreg-properties.py   |  290 +++
 scripts/update-aarch64-cpu-sysregs-header.py  |   51 +
 target/arm/meson.build                        |    1 +
 target/arm/trace-events                       |    7 +
 14 files changed, 3244 insertions(+), 33 deletions(-)
 create mode 100644 target/arm/cpu-idregs.h
 create mode 100644 target/arm/cpu-idregs.h.inc
 create mode 100644 target/arm/cpu-idregs.c
 create mode 100644 scripts/aarch64_sysreg_helpers.py
 create mode 100644 scripts/update-aarch64-cpu-sysreg-properties.py
 create mode 100755 scripts/update-aarch64-cpu-sysregs-header.py

-- 
2.53.0

Re: [RFC PATCH v6 00/17] kvm/arm: Introduce a customizable aarch64 KVM host model

Posted by Khushit Shah 1 day, 4 hours ago


> On 16 Jun 2026, at 6:46 PM, Eric Auger <eric.auger@redhat.com> wrote:
> 
> !-------------------------------------------------------------------|
>  CAUTION: External Email
> 
> |-------------------------------------------------------------------!
> 

Hi Eric, 

Thanks for the v6.

> This series enhances the current host KVM model with capability to
> set writable ID reg fields. 
> 
> Since v6.7 kernel, KVM/arm allows the userspace to overwrite the values
> of a subset of ID regs. The list of writable fields continues to grow.
> The feature ID range is defined as the AArch64 System register space
> with op0==3, op1=={0, 1, 3}, CRn==0, CRm=={0-7}, op2=={0-7}.
> 
> The end goal is to get more flexibility when migrating guests
> between different host hardware.
> 
> QEMU retrieves the writable ID fields from KVM UAPI [1] and
> match them against a generated description of ID regs and their
> named fields that stem from AARCHMRS Registers.json file.
> Current description is based on latest 2026-03 edition.
> The content of the generated files was compared against kernel
> linux/arch/arm64/tools/sysreg file. It is not straightforward
> to have unit tests for python scripts as there are many cases for
> field extraction.
> 
> For each writable named field a uint64 property is created
> following the "SYSREG_<REG>_<FIELD>" naming convention. REG and
> FIELD names are those described in ARM ARM Reference manual.
> 
> The list of SYSREG_ID properties can be retrieved through the qmp
> monitor using query-cpu-model-expansion [2].
> 
> For the record, Jinqian was able to migrate between Hisilicon KunPeng
> HIP09 and HIP12 chips with this series using this kind of command:
> 
> -cpu host,pauth=off,pmu=off,sve=off,\
> SYSREG_ID_AA64PFR1_EL1_NMI=0x0,\
> SYSREG_ID_AA64ISAR1_EL1_LS64=0x0,\
> SYSREG_ID_AA64ISAR1_EL1_XS=0x0,\
> SYSREG_ID_AA64ISAR1_EL1_LRCPC=0x2,\
> SYSREG_ID_AA64ISAR2_EL1_RPRFM=0x0,\
> SYSREG_ID_AA64ISAR2_EL1_CLRBHB=0x0,\
> SYSREG_ID_AA64ISAR2_EL1_PAC_frac=0x0,\
> SYSREG_ID_AA64ISAR2_EL1_BC=0x0,\
> SYSREG_ID_AA64ISAR2_EL1_RPRES=0x0,\
> SYSREG_ID_AA64ISAR2_EL1_WFxT=0x0,\
> SYSREG_ID_AA64MMFR0_EL1_FGT=0x0,\
> SYSREG_ID_AA64MMFR0_EL1_BigEnd=0x0,\
> SYSREG_ID_AA64MMFR1_EL1_ECBHB=0x0,\
> SYSREG_ID_AA64MMFR1_EL1_CMOW=0x0,\
> SYSREG_ID_AA64MMFR1_EL1_TIDCP1=0x0,\
> SYSREG_ID_AA64MMFR1_EL1_nTLBPA=0x0,\
> SYSREG_ID_AA64MMFR1_EL1_AFP=0x0,\
> SYSREG_ID_AA64MMFR1_EL1_HCX=0x0,\
> SYSREG_ID_AA64MMFR1_EL1_ETS=0x0,\
> SYSREG_ID_AA64MMFR1_EL1_PAN=0x2,\
> SYSREG_ID_AA64MMFR1_EL1_HAFDBS=0x2,\
> SYSREG_ID_AA64MMFR2_EL1_CnP=0x0,\
> SYSREG_ID_AA64MMFR3_EL1_TCRX=0x0,\
> SYSREG_ID_AA64DFR0_EL1_PMUVer=0x6,\
> SYSREG_ID_AA64DFR0_EL1_DebugVer=0x9,\
> SYSREG_ID_AA64DFR0_EL1_DoubleLock=0xf,\
> SYSREG_ID_AA64ZFR0_EL1_F64MM=0x0,\
> SYSREG_ID_AA64ZFR0_EL1_F32MM=0x0,\
> SYSREG_ID_AA64ZFR0_EL1_SM4=0x0,\
> SYSREG_ID_AA64ZFR0_EL1_SHA3=0x0,\
> SYSREG_ID_AA64ZFR0_EL1_BitPerm=0x0,\
> SYSREG_ID_AA64ZFR0_EL1_AES=0x0,\
> SYSREG_ID_AA64ZFR0_EL1_SVEver=0x0,\
> SYSREG_CTR_EL0_L1Ip=0x2 \
> 
> Connie & Eric
> 
> This series can be found at:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eauger_qemu_tree_arm-2Dcpu-2Dmodel-2Dv6&d=DwIDAg&c=s883GpUCOChKOHiocYtGcg&r=PGWMyignA0NiDmTlyP7vOTHozBws_VN86yrVmSMkBp0&m=CIDxwz9G74N7XMNYrbkXrfmPGYOEMVyHDG5MW0tgCdgJeSxgHHAZKmHhQLkM8PTn&s=Hlpt4MU__nclTetQfJWeWLwy0ShnarmfgXq4DmGpaGU&e= 
> 
> History:
> --------
> v5 -> v6:
> v6 is mostly for Khushit to see how he may work on top
> of this series. It fulfills some of his requirements:
> - Upon Khushit request I added description for enum values
>  and reserved fields
> - set_sysreg_prop checks the input value against enum values
>  if any
> - writable_bitmap is now dispatched into the sysreg descripton
>  and not stored in vcpu state anymore (besides it is VM wide)
> - implemented write for qmp inspection. However this is not
>  yet checked against KVM. That's the next step I think, ie.
>  instantiate a scratch vcpu to test if the field value can be
>  applied?
> - if some inconsistencies between writable mask and idreg
>  field, reserved fields only produce traces
> - simplify checks related to availability of writable map
> - this version does not yet fix some reported issues about host
>  supporting nested virt. I will further sync with Khushit.
>  so this is definitively not candidate to be applied, hence the
>  RFC tag.

Thanks!, Will use this series as the base for our v3.

Warm Regards,
Khushit
> v4 -> v5:
> - generate target/arm/cpu-idregs.h.inc that look similar to
>  the format used in [RFC PATCH v1 02/13] target/arm:
>  named_cpu_model: Add ID Register Fields without the
>  description of the value values nor safe policy/value.
>  I guess valid values could be generated from the Registers.json
>  file too. Safe policy/values cannot.
>  I reused one patch from the above series.
>  Let's see how both series can progress/coexist without any
>  anticipated bias.
> - Addressed all comments from Shameer on v4
> - Addressed 2 comments from v4 that were missed including the
>  issue of IDreg visibility affected by some other settings.
>  Unfortunately I was not able to test it.
> - Further look at overrides between low level id reg field
>  properties versus legacy CPU options. I have the feeling they
>  can coexist as long as we document the hierarchy between them:
>  host kvm default -> ID reg field props -> legacy CPU options
> - Noticed more writable fields that are RES0/RAZ
> - Improved commit messages in general
> 
> References:
> -----------
> 
> [1]
> KVM_CAP_ARM_SUPPORTED_REG_MASK_RANGES
> KVM_ARM_GET_REG_WRITABLE_MASKS
> Documentation/virt/kvm/api.rst
> 
> [2]
> qemu-system-aarch64 -qmp unix:/home/augere/TEST/QEMU/qmp-sock,server,nowait -M virt --enable-kvm -cpu host
> sudo build/run qmp-shell /home/augere/TEST/QEMU/qmp-sock
> Welcome to the QMP low-level shell!
> Connected to QEMU 11.0.50
> (QEMU) query-cpu-model-expansion type=full model={"name":"host"}
> 
> 
> Cornelia Huck (3):
>  target/arm/kvm: Retrieve writable ID reg map
>  arm-qmp-cmds: introspection for ID register props
>  arm/cpu-features: document ID reg properties
> 
> Eric Auger (13):
>  scripts: introduce scripts/update-aarch64-cpu-sysregs-header.py
>  target/arm/cpu-sysregs.h.inc: Sort by name alphabetical order
>  target/arm/cpu-sysregs.h.inc: Update with automatic generation
>  arm/cpu: Add infra to handle generated ID register definitions
>  scripts: Introduce scripts/aarch64_sysreg_helpers module
>  scripts: Introduce scripts/update-aarch64-cpu-sysreg-properties.py
>  target/arm/cpu-idregs.h.inc: generate with script
>  target/arm/cpu-idregs.h.inc: Generate enum values
>  arm/kvm: Initialize all writable ID registers from host
>  target/arm/kvm: Introduce kvm_arm_expose_idreg_properties
>  target/arm/cpu: Expose writable ID reg field properties on the kvm
>    host vcpu model
>  target/arm/cpu-idregs.h.inc: Generate reserved fields
>  target/arm/kvm: Ignore and trace unexpected writable reserved fields
> 
> Shaju Abraham (1):
>  target/arm/cpu_idregs: generate tables for Arm64 ID registers and
>    fields
> 
> docs/system/arm/cpu-features.rst              |  106 +-
> target/arm/cpu-idregs.h                       |   41 +
> target/arm/kvm_arm.h                          |   10 +
> target/arm/cpu-idregs.h.inc                   | 2164 +++++++++++++++++
> target/arm/cpu-sysregs.h.inc                  |   57 +-
> target/arm/arm-qmp-cmds.c                     |   29 +
> target/arm/cpu-idregs.c                       |   96 +
> target/arm/cpu64.c                            |    5 +
> target/arm/kvm.c                              |  311 ++-
> scripts/aarch64_sysreg_helpers.py             |  109 +
> .../update-aarch64-cpu-sysreg-properties.py   |  290 +++
> scripts/update-aarch64-cpu-sysregs-header.py  |   51 +
> target/arm/meson.build                        |    1 +
> target/arm/trace-events                       |    7 +
> 14 files changed, 3244 insertions(+), 33 deletions(-)
> create mode 100644 target/arm/cpu-idregs.h
> create mode 100644 target/arm/cpu-idregs.h.inc
> create mode 100644 target/arm/cpu-idregs.c
> create mode 100644 scripts/aarch64_sysreg_helpers.py
> create mode 100644 scripts/update-aarch64-cpu-sysreg-properties.py
> create mode 100755 scripts/update-aarch64-cpu-sysregs-header.py
> 
> -- 
> 2.53.0
>

Re: [RFC PATCH v6 00/17] kvm/arm: Introduce a customizable aarch64 KVM host model

Posted by Eric Auger 1 day, 2 hours ago


On 6/17/26 11:31 AM, Khushit Shah wrote:
>
>> On 16 Jun 2026, at 6:46 PM, Eric Auger <eric.auger@redhat.com> wrote:
>>
>> !-------------------------------------------------------------------|
>>  CAUTION: External Email
>>
>> |-------------------------------------------------------------------!
>>
> Hi Eric, 
>
> Thanks for the v6.
>
>> This series enhances the current host KVM model with capability to
>> set writable ID reg fields. 
>>
>> Since v6.7 kernel, KVM/arm allows the userspace to overwrite the values
>> of a subset of ID regs. The list of writable fields continues to grow.
>> The feature ID range is defined as the AArch64 System register space
>> with op0==3, op1=={0, 1, 3}, CRn==0, CRm=={0-7}, op2=={0-7}.
>>
>> The end goal is to get more flexibility when migrating guests
>> between different host hardware.
>>
>> QEMU retrieves the writable ID fields from KVM UAPI [1] and
>> match them against a generated description of ID regs and their
>> named fields that stem from AARCHMRS Registers.json file.
>> Current description is based on latest 2026-03 edition.
>> The content of the generated files was compared against kernel
>> linux/arch/arm64/tools/sysreg file. It is not straightforward
>> to have unit tests for python scripts as there are many cases for
>> field extraction.
>>
>> For each writable named field a uint64 property is created
>> following the "SYSREG_<REG>_<FIELD>" naming convention. REG and
>> FIELD names are those described in ARM ARM Reference manual.
>>
>> The list of SYSREG_ID properties can be retrieved through the qmp
>> monitor using query-cpu-model-expansion [2].
>>
>> For the record, Jinqian was able to migrate between Hisilicon KunPeng
>> HIP09 and HIP12 chips with this series using this kind of command:
>>
>> -cpu host,pauth=off,pmu=off,sve=off,\
>> SYSREG_ID_AA64PFR1_EL1_NMI=0x0,\
>> SYSREG_ID_AA64ISAR1_EL1_LS64=0x0,\
>> SYSREG_ID_AA64ISAR1_EL1_XS=0x0,\
>> SYSREG_ID_AA64ISAR1_EL1_LRCPC=0x2,\
>> SYSREG_ID_AA64ISAR2_EL1_RPRFM=0x0,\
>> SYSREG_ID_AA64ISAR2_EL1_CLRBHB=0x0,\
>> SYSREG_ID_AA64ISAR2_EL1_PAC_frac=0x0,\
>> SYSREG_ID_AA64ISAR2_EL1_BC=0x0,\
>> SYSREG_ID_AA64ISAR2_EL1_RPRES=0x0,\
>> SYSREG_ID_AA64ISAR2_EL1_WFxT=0x0,\
>> SYSREG_ID_AA64MMFR0_EL1_FGT=0x0,\
>> SYSREG_ID_AA64MMFR0_EL1_BigEnd=0x0,\
>> SYSREG_ID_AA64MMFR1_EL1_ECBHB=0x0,\
>> SYSREG_ID_AA64MMFR1_EL1_CMOW=0x0,\
>> SYSREG_ID_AA64MMFR1_EL1_TIDCP1=0x0,\
>> SYSREG_ID_AA64MMFR1_EL1_nTLBPA=0x0,\
>> SYSREG_ID_AA64MMFR1_EL1_AFP=0x0,\
>> SYSREG_ID_AA64MMFR1_EL1_HCX=0x0,\
>> SYSREG_ID_AA64MMFR1_EL1_ETS=0x0,\
>> SYSREG_ID_AA64MMFR1_EL1_PAN=0x2,\
>> SYSREG_ID_AA64MMFR1_EL1_HAFDBS=0x2,\
>> SYSREG_ID_AA64MMFR2_EL1_CnP=0x0,\
>> SYSREG_ID_AA64MMFR3_EL1_TCRX=0x0,\
>> SYSREG_ID_AA64DFR0_EL1_PMUVer=0x6,\
>> SYSREG_ID_AA64DFR0_EL1_DebugVer=0x9,\
>> SYSREG_ID_AA64DFR0_EL1_DoubleLock=0xf,\
>> SYSREG_ID_AA64ZFR0_EL1_F64MM=0x0,\
>> SYSREG_ID_AA64ZFR0_EL1_F32MM=0x0,\
>> SYSREG_ID_AA64ZFR0_EL1_SM4=0x0,\
>> SYSREG_ID_AA64ZFR0_EL1_SHA3=0x0,\
>> SYSREG_ID_AA64ZFR0_EL1_BitPerm=0x0,\
>> SYSREG_ID_AA64ZFR0_EL1_AES=0x0,\
>> SYSREG_ID_AA64ZFR0_EL1_SVEver=0x0,\
>> SYSREG_CTR_EL0_L1Ip=0x2 \
>>
>> Connie & Eric
>>
>> This series can be found at:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eauger_qemu_tree_arm-2Dcpu-2Dmodel-2Dv6&d=DwIDAg&c=s883GpUCOChKOHiocYtGcg&r=PGWMyignA0NiDmTlyP7vOTHozBws_VN86yrVmSMkBp0&m=CIDxwz9G74N7XMNYrbkXrfmPGYOEMVyHDG5MW0tgCdgJeSxgHHAZKmHhQLkM8PTn&s=Hlpt4MU__nclTetQfJWeWLwy0ShnarmfgXq4DmGpaGU&e= 
>>
>> History:
>> --------
>> v5 -> v6:
>> v6 is mostly for Khushit to see how he may work on top
>> of this series. It fulfills some of his requirements:
>> - Upon Khushit request I added description for enum values
>>  and reserved fields
>> - set_sysreg_prop checks the input value against enum values
>>  if any
>> - writable_bitmap is now dispatched into the sysreg descripton
>>  and not stored in vcpu state anymore (besides it is VM wide)
>> - implemented write for qmp inspection. However this is not
>>  yet checked against KVM. That's the next step I think, ie.
>>  instantiate a scratch vcpu to test if the field value can be
>>  applied?
>> - if some inconsistencies between writable mask and idreg
>>  field, reserved fields only produce traces
>> - simplify checks related to availability of writable map
>> - this version does not yet fix some reported issues about host
>>  supporting nested virt. I will further sync with Khushit.
>>  so this is definitively not candidate to be applied, hence the
>>  RFC tag.
> Thanks!, Will use this series as the base for our v3.

OK.

Few notes:
- I saw there are capabilities to define property aliases (source and
destination types must match though). So there could be way to associate
a FEAT_ property to SYSREG property for those who strictly match. 

- In case people would like to have labelled strings, we could turn the
SYSREG props, which are currently uint64 into string props. on set we
would convert the string into the isar uint64.
You could maintain a separate description file that associate enum
values to string values. If an association exists we would do an
intermediate translation.

Thanks

Eric
>
> Warm Regards,
> Khushit
>> v4 -> v5:
>> - generate target/arm/cpu-idregs.h.inc that look similar to
>>  the format used in [RFC PATCH v1 02/13] target/arm:
>>  named_cpu_model: Add ID Register Fields without the
>>  description of the value values nor safe policy/value.
>>  I guess valid values could be generated from the Registers.json
>>  file too. Safe policy/values cannot.
>>  I reused one patch from the above series.
>>  Let's see how both series can progress/coexist without any
>>  anticipated bias.
>> - Addressed all comments from Shameer on v4
>> - Addressed 2 comments from v4 that were missed including the
>>  issue of IDreg visibility affected by some other settings.
>>  Unfortunately I was not able to test it.
>> - Further look at overrides between low level id reg field
>>  properties versus legacy CPU options. I have the feeling they
>>  can coexist as long as we document the hierarchy between them:
>>  host kvm default -> ID reg field props -> legacy CPU options
>> - Noticed more writable fields that are RES0/RAZ
>> - Improved commit messages in general
>>
>> References:
>> -----------
>>
>> [1]
>> KVM_CAP_ARM_SUPPORTED_REG_MASK_RANGES
>> KVM_ARM_GET_REG_WRITABLE_MASKS
>> Documentation/virt/kvm/api.rst
>>
>> [2]
>> qemu-system-aarch64 -qmp unix:/home/augere/TEST/QEMU/qmp-sock,server,nowait -M virt --enable-kvm -cpu host
>> sudo build/run qmp-shell /home/augere/TEST/QEMU/qmp-sock
>> Welcome to the QMP low-level shell!
>> Connected to QEMU 11.0.50
>> (QEMU) query-cpu-model-expansion type=full model={"name":"host"}
>>
>>
>> Cornelia Huck (3):
>>  target/arm/kvm: Retrieve writable ID reg map
>>  arm-qmp-cmds: introspection for ID register props
>>  arm/cpu-features: document ID reg properties
>>
>> Eric Auger (13):
>>  scripts: introduce scripts/update-aarch64-cpu-sysregs-header.py
>>  target/arm/cpu-sysregs.h.inc: Sort by name alphabetical order
>>  target/arm/cpu-sysregs.h.inc: Update with automatic generation
>>  arm/cpu: Add infra to handle generated ID register definitions
>>  scripts: Introduce scripts/aarch64_sysreg_helpers module
>>  scripts: Introduce scripts/update-aarch64-cpu-sysreg-properties.py
>>  target/arm/cpu-idregs.h.inc: generate with script
>>  target/arm/cpu-idregs.h.inc: Generate enum values
>>  arm/kvm: Initialize all writable ID registers from host
>>  target/arm/kvm: Introduce kvm_arm_expose_idreg_properties
>>  target/arm/cpu: Expose writable ID reg field properties on the kvm
>>    host vcpu model
>>  target/arm/cpu-idregs.h.inc: Generate reserved fields
>>  target/arm/kvm: Ignore and trace unexpected writable reserved fields
>>
>> Shaju Abraham (1):
>>  target/arm/cpu_idregs: generate tables for Arm64 ID registers and
>>    fields
>>
>> docs/system/arm/cpu-features.rst              |  106 +-
>> target/arm/cpu-idregs.h                       |   41 +
>> target/arm/kvm_arm.h                          |   10 +
>> target/arm/cpu-idregs.h.inc                   | 2164 +++++++++++++++++
>> target/arm/cpu-sysregs.h.inc                  |   57 +-
>> target/arm/arm-qmp-cmds.c                     |   29 +
>> target/arm/cpu-idregs.c                       |   96 +
>> target/arm/cpu64.c                            |    5 +
>> target/arm/kvm.c                              |  311 ++-
>> scripts/aarch64_sysreg_helpers.py             |  109 +
>> .../update-aarch64-cpu-sysreg-properties.py   |  290 +++
>> scripts/update-aarch64-cpu-sysregs-header.py  |   51 +
>> target/arm/meson.build                        |    1 +
>> target/arm/trace-events                       |    7 +
>> 14 files changed, 3244 insertions(+), 33 deletions(-)
>> create mode 100644 target/arm/cpu-idregs.h
>> create mode 100644 target/arm/cpu-idregs.h.inc
>> create mode 100644 target/arm/cpu-idregs.c
>> create mode 100644 scripts/aarch64_sysreg_helpers.py
>> create mode 100644 scripts/update-aarch64-cpu-sysreg-properties.py
>> create mode 100755 scripts/update-aarch64-cpu-sysregs-header.py
>>
>> -- 
>> 2.53.0
>>

Re: [RFC PATCH v6 00/17] kvm/arm: Introduce a customizable aarch64 KVM host model

Posted by Khushit Shah 1 day, 2 hours ago


> On 17 Jun 2026, at 4:48 PM, Eric Auger <eric.auger@redhat.com> wrote:
> 
> Few notes:
> - I saw there are capabilities to define property aliases (source and
> destination types must match though). So there could be way to associate
> a FEAT_ property to SYSREG property for those who strictly match. 
> 
> - In case people would like to have labelled strings, we could turn the
> SYSREG props, which are currently uint64 into string props. on set we
> would convert the string into the isar uint64.
> You could maintain a separate description file that associate enum
> values to string values. If an association exists we would do an
> intermediate translation.
> 

This is my plan, but for v3 I am not focusing on property types/names.

Let’s get infra/models without that first.

User friendly properties will be a separate effort.

Warm Regards,
Khushit