On Fri, 29 Nov 2024 at 15:10, Cornelia Huck <coh...@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
