On Mon, 11 Nov 2024 at 14:29, Cornelia Huck <coh...@redhat.com> wrote: > That leaves some headscratchers (at least for me.) E.g. FEAT_UINJ, which > is optional from v9.5, and mandatory from v9.6, but where I'm unsure how > we'd discover it, especially as we do not have a way to discover the > architecture extensions.
I think that's just an accidental omission from the FEAT_UINJ documentation. There's a UINJ field in ID_AA64PFR2_EL1 which tells you whether FEAT_UINJ is implemented: https://developer.arm.com/documentation/109697/2024_09/Feature-descriptions/The-Armv9-6-architecture-extension > I'm also not sure if I understand FEAT_CHK, which is listed as > optional from v8.0 and mandatory from v9.4, but every aarch64 cpu is > supposed to be compliant, because CHKFEAT might be a NOP (and this is > only supposed to check for FEAT_GCS? Yes, I'm confused.) CHKFEAT is there for cases where software (especially EL0 software) might need a fast cross-OS-portable way to detect whether a feature is present and enabled -- for instance if you want the compiler to emit a function prologue sequence that includes "do XYZ if GCS is on". CHKFEAT is in the hint area of the encoding space, so for any CPU that pre-dates FEAT_CHK it will do nothing (which is how "no features detectable with CHKFEAT are present" is indicated: if you look at what CHKFEAT actually does it has a definition that isn't how you'd naturally implement a feature-detect unless you needed to make NOP mean no-features-present.) Currently FEAT_GCS is the only feature where it has been deemed necessary to provide this kind of is-it-enabled detection, but some future features might also use the CHKFEAT mechanism. If you're a piece of system software wanting to see if FEAT_GCS is present you would use ID_AA64PFR1_EL1.GCS. (In particular, if you're an OS then until you have enabled GCS for yourself via GCSCR_EL1, CHKFEAT will tell you "not enabled", so you first need to look at the ID register to see if the GCSCR_EL1 register is there at all...) thanks -- PMM
