[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250716153514.GN288056@port70.net>
Date: Wed, 16 Jul 2025 17:35:14 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: aarch64 SME support issues
* 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;
> }
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.
