Re: [RFC] arm: property and value naming summary between named CPU models vs customizable host model

[Cornelia Huck <cohuck@redhat.com>]

On Wed, Jun 10 2026, Khushit Shah <khushit.shah@nutanix.com> wrote:

Thank you for the writeup!

(...)

> I have tried to keep the comparison above neutral, but Eric/Cornelia can
> add more. I see real merit in [2]'s simplicity and generalization. But
> for [1], I love a command line that looks like:
> -cpu host,feat_DP=off,feat_AES=off,feat_RAS=0.0,...
>
> instead of:
> -cpu host \
>      SYSREG_ID_AA64ISAR0_DP=0,\
>      SYSREG_ID_AA64ISAR0_AES=0,\
>      SYSREG_ID_AA64PFR0_RAS=0,\
>      SYSREG_ID_AA64PFR1_RAS_FRAC=0 
>
> I have no strong preference on this topic. The named CPU model layer is
> independent of whichever convention we choose here, so I'd like the
> community to decide which direction makes the most sense :)

I see the human-friendliness of providing prop names as in [1], but I
also see the advantages of generating properties automatically from the
ARM specification in [2]. Maybe there's a way to get the best of both
worlds? Can we expose the feat_XXX properties to users by mapping them
to the relevant registers respectively the combinations of them and
still keep the raw sysregs for those cases where something does not
match to feat_XXX (e.g. some cache values), or just as an alternative
way of configuring things?

Also, we've mostly talked about KVM so far. If we also consider TCG, or
other hypervisors such as HVF, I'd be in favour of grabbing definitions
from the spec, instead of from a specific kernel. (We can still choose
to match the Linux names, but we should not have to.)

There are also some pre-existing properties for cpus; can we express
them via the new interfaces, or do we want to deprecate them, only
keeping those that do not match to hardware, but to accelerator
implementation details?