On Fri, Dec 10, 2021 at 10:41:18AM +0000, Catalin Marinas wrote: > On Thu, Dec 09, 2021 at 07:28:16PM +0000, Mark Brown wrote: > > > > +#define HWCAP2_SME_B16F32 (1 << 25) > > > > +#define HWCAP2_SME_F32F32 (1 << 26) > > > > +#define HWCAP2_SME_FA64 (1 << 27) > > > > > At this pace we'll need HWCAP3 pretty soon (since we only allocated > > > 32-bit in each). I wonder whether we could instead not bother at all and > > > just provide user-space emulation for ID_AA64SMFR0_EL1. > > I think so if people are willing to go along with just having userspace > > check the ID register (IIRC access to it already does the right thing > > but I need to confirm). We'll also need to think about how we handle > > any new SVE features, that's got a similar thing going on and is most of > > the existing usage of HWCAP2. > It would be good to get feedback from the libc people. IIRC the ifunc > resolver relies currently on the HWCAP bits. Could this be adapted to > use the MRS instruction? We'd still keep the main HWCAP2_SME but without > the finer-grained bits. > The other option is to start going into the upper 32-bit of the > elf_hwcap. We tried to avoid this some time back when we were still > having doubts about merging ILP32. I'll leave things as they are just now to give more time for feedback. > > > I'll comment here rather than the patch introducing has_feature_flag(): > > > an alternative would be to add a .field_width option and in > > > feature_matches() use cpuid_feature_extract_field_width() directly. All > > Sure, if people are happy with that - it's a more invasive change since > > we don't currently set the widths, I wasn't clear if that was a case of > > not needing it right now or a design decision. > We didn't have a field_width since they were all 4 bits until SVE. If > you don't want to touch all the entries in the array, we can say that a > 0 value (i.e. not explicitly initialised) means default 4 and update it > during init_cpu_features(). It's annoying to have to update everything but it feels more idiomatic and less likely to cause surprises later on.
Attachment:
signature.asc
Description: PGP signature
