On Fri, 16 Oct 2026 at 13:07, Eric Auger <[email protected]> wrote:
>
> Hi Khushit,
>
> On 9/21/26 2:32 PM, Khushit Shah wrote:
> > Add a KVM-only named CPU model for the Armv9.0-A baseline, following
> > DDI0487 revision M.c. The property list is the architecture-mandated
> > ID-register field view.
> > +static const ArmModelPropValue arm_v9_0_a_v1_props[] = {
> > + /* ID_AA64PFR0_EL1 */
> > + MODEL_PROP("SYSREG_ID_AA64PFR0_EL1_EL0", NUM, 1), /* only FEAT_AA64EL0
> > (Armv9.0) */
> > + MODEL_PROP("SYSREG_ID_AA64PFR0_EL1_EL1", NUM, 1), /* only FEAT_AA64EL1
> > (Armv9.0) */
> > + MODEL_PROP("SYSREG_ID_AA64PFR0_EL1_RAS", NUM, 1), /* FEAT_RAS
> > (Armv8.2) */
> > + MODEL_PROP("SYSREG_ID_AA64PFR0_EL1_DIT", NUM, 1), /* FEAT_DIT
> > (Armv8.4) */
> > + MODEL_PROP("SYSREG_ID_AA64PFR0_EL1_CSV2", NUM, 1), /* FEAT_CSV2
> > (Armv8.5) */
> > + MODEL_PROP("SYSREG_ID_AA64PFR0_EL1_CSV3", NUM, 1), /* FEAT_CSV3
> > (Armv8.5) */
> > + MODEL_PROP("SYSREG_ID_AA64PFR0_EL1_FP", NUM, 1), /* FEAT_FP16 */
> > + MODEL_PROP("SYSREG_ID_AA64PFR0_EL1_AdvSIMD", NUM, 1), /* FEAT_FP16 */
> I have not found that FP+AdvSIMD (ie FEAT_FP16) were mandated by v9.0
> amybe you want this model to implement FP16 but it does not seems
> strictly mandated in v9.0
> so it might be distinguished from other settings that are truly mandated.
FP/AdvSIMD is one of those things that's technically optional (because
you might have some extremely-embedded special purpose device that
doesn't want FP) but in practice is mandatory. (The Arm ARM says
"This option [no FP] is licensed only for implementations targeting
specialized markets". Anything that might be running Linux and KVM
is not that.
> > +
> > + /* ID_AA64PFR1_EL1 */
> > + /* KVM zeroes out these field when MTE is not enabled. */
> > + MODEL_PROP("SYSREG_ID_AA64PFR1_EL1_MTE_frac", NUM, 0),
> useless as default is 0, no?
> > + MODEL_PROP("SYSREG_ID_AA64PFR1_EL1_BT", NUM, 1), /* FEAT_BTI (Armv8.5)
> > */
>
>
> > +
> > + /* ID_AA64MMFR0_EL1 */
> > + MODEL_PROP("SYSREG_ID_AA64MMFR0_EL1_TGran64", NUM, 0xF), /* not
> > mandatory */
> > + MODEL_PROP("SYSREG_ID_AA64MMFR0_EL1_TGran4", NUM, 0), /* 4K granular
> > support */
> > + MODEL_PROP("SYSREG_ID_AA64MMFR0_EL1_TGran16_2", NUM, 1), /* not
> > mandatory */
> > + MODEL_PROP("SYSREG_ID_AA64MMFR0_EL1_TGran64_2", NUM, 1), /* not
> > mandatory */
> > + MODEL_PROP("SYSREG_ID_AA64MMFR0_EL1_TGran4_2", NUM, 1), /* not
> > mandatory */
> so the top comment, ie.
>
> +/* Arm-v9.0-a mandatory features. */
>
> should really be updated accordingly. None of that is mandated by v9.0
> spec, right?
The comments here are confusing, because what we really want to point
out here is that for these fields the "not implemented" value is not
always "0" (in some cases it's 0b1111 and in some 0b0001). Where we
set some non-0 value that is the "not implemented" value we should
say that.
Also, no particular granule size is mandatory; you just need to support
at least one, and 4K is most popular, but you can have just 16K or
just 64K if you want. So this is making an actual choice.
-- PMM
