On Fri, Nov 29 2024, Peter Maydell <peter.mayd...@linaro.org> wrote: > 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.)
Ah yes, I actually noticed FEAT_HAFDBS as well. > >> 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. Ok, that one I missed in the list; if there's a feature, we should be able to use it. > >> 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. Indeed, I hope that this will be the case for new features.
