On 5/27/26 6:11 PM, Khushit Shah wrote:
>
>> On 27 May 2026, at 9:34 PM, Eric Auger <[email protected]> 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
