[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250716165137.GF1827@brightrain.aerifal.cx>
Date: Wed, 16 Jul 2025 12:51:37 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: aarch64 SME support issues
On Wed, Jul 16, 2025 at 05:35:14PM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@...c.org> [2025-07-12 22:12:41 -0400]:
> > On Thu, Jul 10, 2025 at 12:47:32AM +0200, Szabolcs Nagy wrote:
> > > * Rich Felker <dalias@...c.org> [2025-07-09 15:02:35 -0400]:
> > > > On Wed, Jul 09, 2025 at 02:45:54PM -0400, Rich Felker wrote:
> > > > 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?
> > >
> > > yeah i'd mask them all even if in principle
> > > HWCAP2_SME should be enough. i don't think
> > > any of the non-SME hwcaps imply HWCAP2_SME.
> > >
> > > if we mask future bits then i think HWCAP3 should
> > > be masked too. there are no bits defined yet, so
> > > no existing kernel would pass it in auxv yet, but
> > > once it is passed musl should return 0 for it.
> > >
> > > i just fear that if ppl figure out that musl is
> > > masking bits they will try to work it around by
> > > using whacky cpu feature detection. so ideally
> > > we don't keep masking forever (i can look into
> > > adding sme support, but not right now).
> >
> > Proposed code attached.
> >
> > Rich
>
> code looks good.
>
> > #include <elf.h>
> > #include "libc.h"
> >
> > #define BITRANGE(a,b) (2*(1UL<<(b))-(1UL<<(a)))
> >
> > int __set_thread_area(void *p)
> > {
> > __asm__ __volatile__ ("msr tpidr_el0,%0" : : "r"(p) : "memory");
> >
> > /* Mask off hwcap bits for SME and unknown future features. This is
> > * necessary because SME is not safe to use without libc support for
> > * it, and we do not (yet) have such support. */
> > for (size_t *v = libc.auxv; *v; v+=2) {
> > if (v[0]==AT_HWCAP) {
> > v[1] &= ~BITRANGE(42,63); /* 42-47 are SME */
> > } else if (v[0]==AT_HWCAP2) {
> > v[1] &= ~(BITRANGE(23,30)
> > | BITRANGE(37,42)
> > | BITRANGE(57,62));
> > } else if (v[0]==AT_HWCAP3 || v[0]==AT_HWCAP4) {
> > v[0] = AT_IGNORE;
> > v[1] = 0;
> > }
> > }
> >
> > return 0;
> > }
OK, merging. I'll push this with a commit message and the other stuff
I'd been holding off on til this issue was resolved.
Thanks for the feedback/help!
Rich
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.
