Re: [PATCH v5 16/18] target/arm/cpu: Expose writable ID reg field properties on the kvm host vcpu model
Hi Khushit, On 5/28/26 7:29 AM, Khushit Shah wrote: > >> On 27 May 2026, at 10:50 PM, Eric Auger wrote: >> >> My reasoning was: >> >> arm_cpu_post_init >> ---> kvm_arm_add_vcpu_properties >> ---> set_sysreg_prop set the new value in cpu->isar.idregs >> arm_cpu_finalize_features >> ---> arm_cpu_sve_finalize >> ---> arm_cpu_sme_finalize >> ---> arm_cpu_pauth_finalize >> ../.. >> those fonctions do some subsequent isar accesses >> >> So I think in general id reg field settings are applied before composite >> legacy options >> >> Thanks >> >> Eric > > > Nope, kvm_arm_add_vcpu_properties, just adds KVM specific properties. right, wrong copy/paste. kvm_arm_add_vcpu_properties just registers the props > > Right now, set_sysreg_prop are called along with legacy props during Yes options are applied in order but the difference is ID reg field props settings directly touch the isar array while others are stored in some temporary field in either machine or cpu code and analyzed later, for what I see in arm_cpu_realizefn(), either in arm_cpu_finalize_features() or directly in the body. So isar access related to compositive functions should be done after those related to new SYSREG_REG_FIELD props. However I acknoledge the requires a case by case check and testing. Thanks Eric > > The call stack is: > machvirt_init > > set cpu specific machine_props (has-el2, has-el3, mp-affinity) > > dev_realize(cpu) > > set cmd cpu props (prop set in order they appear in cmdline) > > > Warm Regards, > Khushit
Re: [PATCH v5 16/18] target/arm/cpu: Expose writable ID reg field properties on the kvm host vcpu model
On 5/27/26 6:11 PM, Khushit Shah wrote: > >> On 27 May 2026, at 9:34 PM, Eric Auger wrote: >> >> On 5/27/26 5:56 PM, Khushit Shah wrote: >>> So you are saying, if I do, >>> -cpu host,sve=on,SYSREG_ID_AA64PFR0_SVE=0 >>> QEMU will still show sve capabilities to the guest? >> Yes that's what I expect. Require more extensive testing though. That >> could be way to handle coexistence of different levels of granulaity. >> Lowest level applies first, overriden by legacy compositive options. I >> guess if you plan to introduce other layers of compositive props you >> will most probably handle this situation too. >> > I am sure this at-least does not work with sve, > because arm_cpu_sve_finalize() just takes looks at the PFR0.SVE field and If > value is 0 sve is 'off' otherwise 'on’. ID_AA64PFR0_EL1 SVE field is not writable if I am not wrong. Only ID_AA64ZFR0_EL1.SVEver is ID_FILTERED(ID_AA64PFR0_EL1, id_aa64pfr0_el1, ~(ID_AA64PFR0_EL1_AMU | ID_AA64PFR0_EL1_MPAM | ID_AA64PFR0_EL1_SVE | ID_AA64PFR0_EL1_AdvSIMD | ID_AA64PFR0_EL1_FP)), Eric > > What you describe might work for legacy props backed by prop_* boolean > variables in ARMCPU like pauth (backed by cpu->prop_pauth). > > I have not tested this. I maybe wrong if some prop ordering magic happens at > machine level. > > My plan is to just parse properties in order they arrive in cmdline :) > > Warm Regards, > Khushit
Re: [PATCH v5 16/18] target/arm/cpu: Expose writable ID reg field properties on the kvm host vcpu model
> On 27 May 2026, at 10:50 PM, Eric Auger wrote: > > My reasoning was: > > arm_cpu_post_init > ---> kvm_arm_add_vcpu_properties > ---> set_sysreg_prop set the new value in cpu->isar.idregs > arm_cpu_finalize_features > ---> arm_cpu_sve_finalize > ---> arm_cpu_sme_finalize > ---> arm_cpu_pauth_finalize > ../.. > those fonctions do some subsequent isar accesses > > So I think in general id reg field settings are applied before composite > legacy options > > Thanks > > Eric Nope, kvm_arm_add_vcpu_properties, just adds KVM specific properties. Right now, set_sysreg_prop are called along with legacy props during The call stack is: machvirt_init > set cpu specific machine_props (has-el2, has-el3, mp-affinity) > dev_realize(cpu) > set cmd cpu props (prop set in order they appear in cmdline) Warm Regards, Khushit
Re: [PATCH v5 16/18] target/arm/cpu: Expose writable ID reg field properties on the kvm host vcpu model
On 5/27/26 6:11 PM, Khushit Shah wrote: > >> On 27 May 2026, at 9:34 PM, Eric Auger wrote: >> >> On 5/27/26 5:56 PM, Khushit Shah wrote: >>> So you are saying, if I do, >>> -cpu host,sve=on,SYSREG_ID_AA64PFR0_SVE=0 >>> QEMU will still show sve capabilities to the guest? >> Yes that's what I expect. Require more extensive testing though. That >> could be way to handle coexistence of different levels of granulaity. >> Lowest level applies first, overriden by legacy compositive options. I >> guess if you plan to introduce other layers of compositive props you >> will most probably handle this situation too. >> > I am sure this at-least does not work with sve, > because arm_cpu_sve_finalize() just takes looks at the PFR0.SVE field and If > value is 0 sve is 'off' otherwise 'on’. My reasoning was: arm_cpu_post_init ---> kvm_arm_add_vcpu_properties ---> set_sysreg_prop set the new value in cpu->isar.idregs arm_cpu_finalize_features ---> arm_cpu_sve_finalize ---> arm_cpu_sme_finalize ---> arm_cpu_pauth_finalize ../.. those fonctions do some subsequent isar accesses So I think in general id reg field settings are applied before composite legacy options Thanks Eric > > What you describe might work for legacy props backed by prop_* boolean > variables in ARMCPU like pauth (backed by cpu->prop_pauth). > > I have not tested this. I maybe wrong if some prop ordering magic happens at > machine level. > > My plan is to just parse properties in order they arrive in cmdline :) > > Warm Regards, > Khushit
Re: [PATCH v5 16/18] target/arm/cpu: Expose writable ID reg field properties on the kvm host vcpu model
> On 27 May 2026, at 9:34 PM, Eric Auger wrote: > > On 5/27/26 5:56 PM, Khushit Shah wrote: >> So you are saying, if I do, >> -cpu host,sve=on,SYSREG_ID_AA64PFR0_SVE=0 >> QEMU will still show sve capabilities to the guest? > Yes that's what I expect. Require more extensive testing though. That > could be way to handle coexistence of different levels of granulaity. > Lowest level applies first, overriden by legacy compositive options. I > guess if you plan to introduce other layers of compositive props you > will most probably handle this situation too. > I am sure this at-least does not work with sve, because arm_cpu_sve_finalize() just takes looks at the PFR0.SVE field and If value is 0 sve is 'off' otherwise 'on’. What you describe might work for legacy props backed by prop_* boolean variables in ARMCPU like pauth (backed by cpu->prop_pauth). I have not tested this. I maybe wrong if some prop ordering magic happens at machine level. My plan is to just parse properties in order they arrive in cmdline :) Warm Regards, Khushit
Re: [PATCH v5 16/18] target/arm/cpu: Expose writable ID reg field properties on the kvm host vcpu model
On 5/27/26 5:56 PM, Khushit Shah wrote: > So you are saying, if I do, > -cpu host,sve=on,SYSREG_ID_AA64PFR0_SVE=0 > QEMU will still show sve capabilities to the guest? Yes that's what I expect. Require more extensive testing though. That could be way to handle coexistence of different levels of granulaity. Lowest level applies first, overriden by legacy compositive options. I guess if you plan to introduce other layers of compositive props you will most probably handle this situation too. Thanks Eric
Re: [PATCH v5 16/18] target/arm/cpu: Expose writable ID reg field properties on the kvm host vcpu model
> On 27 May 2026, at 9:21 PM, Eric Auger wrote: > > Actually I think it works that way already because we first override the > values with ID reg field prop values and then apply the legacy composite > props > So you are saying, if I do, -cpu host,sve=on,SYSREG_ID_AA64PFR0_SVE=0 QEMU will still show sve capabilities to the guest? Warm regards, Khushit
Re: [PATCH v5 16/18] target/arm/cpu: Expose writable ID reg field properties on the kvm host vcpu model
On 5/27/26 5:16 PM, Khushit Shah wrote:
>
>> On 19 May 2026, at 6:57 PM, Eric Auger wrote:
>>
>> !---|
>> CAUTION: External Email
>>
>> |---!
>>
>> If the host supports KVM_CAP_ARM_SUPPORTED_REG_MASK_RANGES and
>> KVM_ARM_GET_REG_WRITABLE_MASKS ioctl successfully retrieved the mask
>> of writable fields for all ID regs, expose uint64 SYSREG properties
>> for all the writable ID reg fields exposed by the host kernel which
>> can be matched in target/arm/cpu-idregs.h.inc.
>>
>> Properties are named SYSREG__ with REG and FIELD
>> being those used ARCHMRS Registers.json.
>>
>> When such properties are set, they override the default field value
>> retrieved from the host and reinjected into KVM. Then the actual value
>> being applied at KVM depends on the register, ie. it can be sanitized.
>> In case the field value is rejected by KVM, the vpcu init fails.
>>
>> Anyway there is a first attempt to write back this value into KVM.
>>
>> Then legacy CPU options (virtualization, secure, ...) can still
>> override the previous value. So low level IDREG field properties
>> apply before the legacy ones.
> No code to handle this right now right? Anyway I just think parse the
> props in order they are specified in command line.
Actually I think it works that way already because we first override the
values with ID reg field prop values and then apply the legacy composite
props
>
> qmp cpu-model-expansion is a weird case, it defines an order in which
> props are processed.
Yeah that's effectively something that needs to be further tested
Thanks
Eric
>
>> An example of invocation is:
>> -cpu host,SYSREG_ID_AA64MMFR0_EL1_ECV=0x0
>> which sets ECV field of ID_AA64MMFR0_EL1 to 0 (enhanced counter
>> virtualization).
>> Signed-off-by: Eric Auger
>> Signed-off-by: Cornelia Huck
>>
>> ---
>> v4 -> v5:
>> - get rid of ret local variable, dynamically allocate and free writable_map
>> here
>> ---
>> target/arm/cpu64.c | 11 ---
>> 1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
>> index f2edbfc437..e0e1ff6cfb 100644
>> --- a/target/arm/cpu64.c
>> +++ b/target/arm/cpu64.c
>> @@ -37,6 +37,7 @@
>> #include "hw/core/qdev-properties.h"
>> #include "internals.h"
>> #include "cpu-features.h"
>> +#include "cpu-idregs.h"
>>
>> /* convert between _IDX and SYS_ */
>> #define DEF(NAME, OP0, OP1, CRN, CRM, OP2) \
>> @@ -851,7 +852,6 @@ static void kvm_arm_set_cpreg_mig_tolerances(ARMCPU *cpu)
>> static void aarch64_host_initfn(Object *obj)
>> {
>> ARMCPU *cpu = ARM_CPU(obj);
>> -int ret;
>>
>> #if defined(CONFIG_NITRO)
>> if (nitro_enabled()) {
>> @@ -865,13 +865,18 @@ static void aarch64_host_initfn(Object *obj)
>>
>> cpu->writable_map = g_new(uint64_t, KVM_ARM_FEATURE_ID_RANGE_SIZE);
>>
>> -ret = kvm_arm_get_writable_id_regs(cpu->writable_map);
>> -if (ret) {
>> +if (kvm_arm_get_writable_id_regs(cpu->writable_map)) {
>> g_free(cpu->writable_map);
>> cpu->writable_map = NULL;
>> }
>> kvm_arm_set_cpu_features_from_host(cpu);
>> aarch64_add_sve_properties(obj);
>> +
>> +if (cpu->writable_map) {
>> +/* generate SYSREG properties according to writable masks */
>> +kvm_arm_expose_idreg_properties(cpu, arm64_id_regs);
>> +}
>> +
>> #elif defined(CONFIG_HVF)
>> hvf_arm_set_cpu_features_from_host(cpu);
>> #elif defined(CONFIG_WHPX)
>> --
>> 2.53.0
>>
> Warm Regards,
> Khushit
>
Re: [PATCH v5 16/18] target/arm/cpu: Expose writable ID reg field properties on the kvm host vcpu model
> On 19 May 2026, at 6:57 PM, Eric Auger wrote:
>
> !---|
> CAUTION: External Email
>
> |---!
>
> If the host supports KVM_CAP_ARM_SUPPORTED_REG_MASK_RANGES and
> KVM_ARM_GET_REG_WRITABLE_MASKS ioctl successfully retrieved the mask
> of writable fields for all ID regs, expose uint64 SYSREG properties
> for all the writable ID reg fields exposed by the host kernel which
> can be matched in target/arm/cpu-idregs.h.inc.
>
> Properties are named SYSREG__ with REG and FIELD
> being those used ARCHMRS Registers.json.
>
> When such properties are set, they override the default field value
> retrieved from the host and reinjected into KVM. Then the actual value
> being applied at KVM depends on the register, ie. it can be sanitized.
> In case the field value is rejected by KVM, the vpcu init fails.
>
> Anyway there is a first attempt to write back this value into KVM.
>
> Then legacy CPU options (virtualization, secure, ...) can still
> override the previous value. So low level IDREG field properties
> apply before the legacy ones.
No code to handle this right now right? Anyway I just think parse the
props in order they are specified in command line.
qmp cpu-model-expansion is a weird case, it defines an order in which
props are processed.
> An example of invocation is:
> -cpu host,SYSREG_ID_AA64MMFR0_EL1_ECV=0x0
> which sets ECV field of ID_AA64MMFR0_EL1 to 0 (enhanced counter
> virtualization).
> Signed-off-by: Eric Auger
> Signed-off-by: Cornelia Huck
>
> ---
> v4 -> v5:
> - get rid of ret local variable, dynamically allocate and free writable_map
> here
> ---
> target/arm/cpu64.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
> index f2edbfc437..e0e1ff6cfb 100644
> --- a/target/arm/cpu64.c
> +++ b/target/arm/cpu64.c
> @@ -37,6 +37,7 @@
> #include "hw/core/qdev-properties.h"
> #include "internals.h"
> #include "cpu-features.h"
> +#include "cpu-idregs.h"
>
> /* convert between _IDX and SYS_ */
> #define DEF(NAME, OP0, OP1, CRN, CRM, OP2) \
> @@ -851,7 +852,6 @@ static void kvm_arm_set_cpreg_mig_tolerances(ARMCPU *cpu)
> static void aarch64_host_initfn(Object *obj)
> {
> ARMCPU *cpu = ARM_CPU(obj);
> -int ret;
>
> #if defined(CONFIG_NITRO)
> if (nitro_enabled()) {
> @@ -865,13 +865,18 @@ static void aarch64_host_initfn(Object *obj)
>
> cpu->writable_map = g_new(uint64_t, KVM_ARM_FEATURE_ID_RANGE_SIZE);
>
> -ret = kvm_arm_get_writable_id_regs(cpu->writable_map);
> -if (ret) {
> +if (kvm_arm_get_writable_id_regs(cpu->writable_map)) {
> g_free(cpu->writable_map);
> cpu->writable_map = NULL;
> }
> kvm_arm_set_cpu_features_from_host(cpu);
> aarch64_add_sve_properties(obj);
> +
> +if (cpu->writable_map) {
> +/* generate SYSREG properties according to writable masks */
> +kvm_arm_expose_idreg_properties(cpu, arm64_id_regs);
> +}
> +
> #elif defined(CONFIG_HVF)
> hvf_arm_set_cpu_features_from_host(cpu);
> #elif defined(CONFIG_WHPX)
> --
> 2.53.0
>
Warm Regards,
Khushit
Re: [PATCH v5 16/18] target/arm/cpu: Expose writable ID reg field properties on the kvm host vcpu model
On Tue, 19 May 2026, Eric Auger wrote: If the host supports KVM_CAP_ARM_SUPPORTED_REG_MASK_RANGES and KVM_ARM_GET_REG_WRITABLE_MASKS ioctl successfully retrieved the mask of writable fields for all ID regs, expose uint64 SYSREG properties for all the writable ID reg fields exposed by the host kernel which can be matched in target/arm/cpu-idregs.h.inc. Properties are named SYSREG__ with REG and FIELD being those used ARCHMRS Registers.json. When such properties are set, they override the default field value retrieved from the host and reinjected into KVM. Then the actual value being applied at KVM depends on the register, ie. it can be sanitized. In case the field value is rejected by KVM, the vpcu init fails. Anyway there is a first attempt to write back this value into KVM. Then legacy CPU options (virtualization, secure, ...) can still override the previous value. So low level IDREG field properties apply before the legacy ones. An example of invocation is: -cpu host,SYSREG_ID_AA64MMFR0_EL1_ECV=0x0 which sets ECV field of ID_AA64MMFR0_EL1 to 0 (enhanced counter virtualization). Signed-off-by: Eric Auger Signed-off-by: Cornelia Huck Reviewed-by: Sebastian Ott
