Re: [RFC 18/21] arm/cpu: Introduce a customizable kvm host cpu model

[Peter Maydell <peter.maydell@linaro.org>]

On Fri, 29 Nov 2024 at 15:10, Cornelia Huck <cohuck@redhat.com> wrote:
> The good news is that in many cases we only have differences in bits
> that map to a feature (and are actually writable in current KVM.) The
> bad news is that we have a number of exceptions.
>
> Comparison #1:
>
> ID_AA64DFR0
> f010307009      #of breakpoints:7
> f010305009      #of breakpoints:5
>
> BRPs does not match to any feature (but has a different meaning when we
> have FEAT_Debugv8p9 and 16+ breakpoints)
> [this is a whole can of worms in general]
>
> ID_AA64MMFR0
> 2100022200101026        FEAT_ECV, FEAT_FGT, 4PB
> 0000022200101125        mixed endian, 256TB
>
> FEAT_ECV -> may be 1 or 2 in ECV, with different capabilities (I guess
> we would need to allow something like FEAT_ECV=2 to expess this?)

This one was an unfortunate oversight; I expect that there
will be a separate feature name for the =2 case in some future
spec release. But as you note for FEAT_BBM below, not
every different ID field value always has its own FEAT_ name.
(FEAT_HAFDBS is another -- it allows ID_AA64MMFR1_EL1.HAFDBS to
be 1 or 2.)

> support for mixed endian -> indicated in BigEnd, no feature (how
> relevant is this in practice?)

ID_AA64MMFR0_EL1.BigEnd == 1 is FEAT_MixedEnd. Relevant if your
guest or its userspace wants to use big-endian, which is probably
approximately nobody in a KVM context but is theoretically possible.

> PARange (52 bits/4PB vs 48 bits/256TB) -> no feature, but some values
> depend on other features -- we care about this when creating a cpu, but
> migrating to another system with a mismatched range would be
> problematic, unless configuration outside of the cpu model would take
> care of it
>
> Comparison #2:
>
> ID_AA64PFR0
> 1101011021111111        FEAT_AMUv1, GIC v3.0/4.0
> 1101001020111111
>
> GIC == 1 indicates GIC CPU sysreg interface for 3.0/4.0, but no feature
> (I'm not quite sure how we handle this in QEMU)

We basically defer GIC emulation almost entirely to the
kernel (which will set the GIC bit in the ID registers
according to whether userspace asked it for a GIC or not).

> ID_AA64MMFR1
> 1000000010312122        FEAT_ECBHB, !FEAT_ETS2, FEAT_PAN3, FEAT_HPDS2, FEAT_HAFDBS
> 0000001010211120        !FEAT_ETS2, FEAT_PAN2, FEAT_HPDS
>
> both ETS == 0 and ETS == 1 indicate that FEAT_ETS2 is not implememented
> (ETS == 2 would indicate FEAT_ETS2) -- I guess we would want to
> standardize on ETS == 0
> FEAT_PAN3 implies FEAT_PAN2, and FEAT_HPDS2 implies FEAT_HPDS2, so
> probably fine

Yes, in general if the number in the field gets bigger
this should be a backwards-compatible improvement in
the feature.

thanks
-- PMM