The 04/28/2022 10:19, Catalin Marinas wrote: > On Tue, Apr 19, 2022 at 12:22:12PM +0100, Mark Brown wrote: > > +* There are a number of optional SME features, presence of these is reported > > + through AT_HWCAP2 through: > > + > > + HWCAP2_SME_I16I64 > > + HWCAP2_SME_F64F64 > > + HWCAP2_SME_I8I32 > > + HWCAP2_SME_F16F32 > > + HWCAP2_SME_B16F32 > > + HWCAP2_SME_F32F32 > > + HWCAP2_SME_FA64 > > Marc pointed out that in combination with FEAT_WFxT, we used all the > HWCAP2 bits (32). While we are ok for now, we'll soon need to look into > what to do when the next features turn up. Some options: > > 1. Only provide HWCAP2_SME and let the ID_AA64SMFR0_EL1 features be > probed via MRS emulation. It doesn't solve the problem but it buys us > a bit of time. > > 2. Don't bother with any new HWCAPs, just rely on MRS emulation (we have > HWCAP_CPUID advertising this). > > 3. Start using the upper 32-bit of HWCAP and HWCAP2 (we initially didn't > go into these as there was a slight chance of merging ILP32). Does > the libc rely on the upper bits for anything? Or does it just assume > a 32-bit HWCAPs layout? top 2 bits of a 64bit AT_HWCAP should be reserved for libc. (glibc uses them internally) otherwise glibc can work with 64bit hwcaps. > > 4. Introduce HWCAP3. > > Szabolcs, any thoughts? i'd go with AT_HWCAP3 and keep using the bottom 32bit for now. (this requires some new code in glibc, but not excessive) thanks. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
