[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250709190234.GR1827@brightrain.aerifal.cx>
Date: Wed, 9 Jul 2025 15:02:35 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: aarch64 SME support issues
On Wed, Jul 09, 2025 at 02:45:54PM -0400, Rich Felker wrote:
> On Wed, Jul 09, 2025 at 04:26:46PM +0200, Szabolcs Nagy wrote:
> > > Do you have a recommendation/preference beween masking it off or
> > > dropping the __getauxval exposure for now?
> > >
> > > I think I'd rather mask it off, since in the (unusual but plausible)
> > > case where a static-only toolchain is built, I think the libgccc
> > > configure test will see the hidden __getauxval and be able to use it
> > > already.
> > >
> > > And if we do masking, I think it makes sense to mask off all unknown
> > > bits so this doesn't happen again in the future with the next new
> > > thing, but I'm not sure. Does this sound reasonable? Are there any
> > > cases where *hiding* a hwcap bit could result in malfunction?
> >
> > ok i hadnt considered the __getauxval change, i think that
> > is useful to go in: it will take time to safely update libgcc
> > so better to add it sooner and potentially more widely useful
> > than just for SME.
> >
> > i think hiding a hwcap bit may lead to inconsistencies due
> > to kernel behaving differently than what libc pretends,
> > but i don't have a strong case, it likely can only affect
> > hacky code. so likely no abi break for normal code.
>
> Yes that's what I'd expect.
>
> > e.g. kernel enables BTI on vdso (or static exe) and user code
> > trying to indirect jump into the middle of a function after
> > checking via the libc hwcap that bti is off.
> >
> > or creating MTE tagged objects via mprotect + instructions
> > based on cpuid and then passing them to a function that is
> > only MTE safe when HWCAP_MTE is set.
>
> Note that we don't need to mask off any caps we already know the
> semantics for, only SME and possibly as-yet-unassigned ones we don't
> know will be safe without libc support.
>
> > or different part of atomics code trying to detect 128bit
> > lse atomics support differently (hwcap vs cpuid).
> >
> > note that HWCAP2 is all used up, and now the top 32 bits
> > of HWCAP are getting allocated (used to be reserved when
> > we thought ilp32 was a thing, now only the top 2 bits are
> > kept for libc to use), musl does not have AT_HWCAP3 but
> > user code may query that anyway as AT_* values are abi.
> > not sure if you plan to deal with AT_HWCAP3 too.
> >
> > i think masking HWCAP_SME* and top bits of AT_HWCAP
> > above 1<<41 should be fine for now. presumably this
> > can be undone if sme support is added.
>
> Sounds good. Should we add and mask hwcap3 too?
Hmm, it looks like there are hwcap2 sme bits:
#define HWCAP2_SME (1 << 23)
#define HWCAP2_SME_I16I64 (1 << 24)
#define HWCAP2_SME_F64F64 (1 << 25)
#define HWCAP2_SME_I8I32 (1 << 26)
#define HWCAP2_SME_F16F32 (1 << 27)
#define HWCAP2_SME_B16F32 (1 << 28)
#define HWCAP2_SME_F32F32 (1 << 29)
#define HWCAP2_SME_FA64 (1 << 30)
...
#define HWCAP2_SME2 (1UL << 37)
#define HWCAP2_SME2P1 (1UL << 38)
#define HWCAP2_SME_I16I32 (1UL << 39)
#define HWCAP2_SME_BI32I32 (1UL << 40)
#define HWCAP2_SME_B16B16 (1UL << 41)
#define HWCAP2_SME_F16F16 (1UL << 42)
...
#define HWCAP2_SME_LUTV2 (1UL << 57)
#define HWCAP2_SME_F8F16 (1UL << 58)
#define HWCAP2_SME_F8F32 (1UL << 59)
#define HWCAP2_SME_SF8FMA (1UL << 60)
#define HWCAP2_SME_SF8DP4 (1UL << 61)
#define HWCAP2_SME_SF8DP2 (1UL << 62)
Not clear if any others are SME-related.
In plain hwcap I see:
#define HWCAP_SME2P2 (1UL << 42)
#define HWCAP_SME_SBITPERM (1UL << 43)
#define HWCAP_SME_AES (1UL << 44)
#define HWCAP_SME_SFEXPA (1UL << 45)
#define HWCAP_SME_STMOP (1UL << 46)
#define HWCAP_SME_SMOP4 (1UL << 47)
And no hwcap3 bits defined yet.
Should the above all be masked? Any I missed?
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
