Message ID | a406b535-dc55-4856-8ae9-5a063644a1af@linux.ibm.com (mailing list archive) |
---|---|
State | Accepted |
Commit | 3281366a8e79a512956382885091565db1036b64 |
Headers | show |
Series | [v2] uapi/auxvec: Define AT_HWCAP3 and AT_HWCAP4 aux vector, entries | expand |
Context | Check | Description |
---|---|---|
snowpatch_ozlabs/github-powerpc_sparse | success | Successfully ran 4 jobs. |
snowpatch_ozlabs/github-powerpc_clang | success | Successfully ran 6 jobs. |
snowpatch_ozlabs/github-powerpc_kernel_qemu | success | Successfully ran 23 jobs. |
On Wed, Feb 14, 2024, at 23:34, Peter Bergner wrote: > The powerpc toolchain keeps a copy of the HWCAP bit masks in our TCB for fast > access by the __builtin_cpu_supports built-in function. The TCB space for > the HWCAP entries - which are created in pairs - is an ABI extension, so > waiting to create the space for HWCAP3 and HWCAP4 until we need them is > problematical. Define AT_HWCAP3 and AT_HWCAP4 in the generic uapi header > so they can be used in glibc to reserve space in the powerpc TCB for their > future use. > > I scanned through the Linux and GLIBC source codes looking for unused AT_* > values and 29 and 30 did not seem to be used, so they are what I went > with. This has received Acked-by's from both GLIBC and Linux kernel > developers and no reservations or Nacks from anyone. > > Arnd, we seem to have consensus on the patch below. Is this something > you could take and apply to your tree? > I don't mind taking it, but it may be better to use the powerpc tree if that is where it's actually being used. If Michael takes it, please add Acked-by: Arnd Bergmann <arnd@arndb.de> Arnd
On 2/15/24 2:16 AM, Arnd Bergmann wrote: > On Wed, Feb 14, 2024, at 23:34, Peter Bergner wrote: >> The powerpc toolchain keeps a copy of the HWCAP bit masks in our TCB for fast >> access by the __builtin_cpu_supports built-in function. The TCB space for >> the HWCAP entries - which are created in pairs - is an ABI extension, so >> waiting to create the space for HWCAP3 and HWCAP4 until we need them is >> problematical. Define AT_HWCAP3 and AT_HWCAP4 in the generic uapi header >> so they can be used in glibc to reserve space in the powerpc TCB for their >> future use. >> >> I scanned through the Linux and GLIBC source codes looking for unused AT_* >> values and 29 and 30 did not seem to be used, so they are what I went >> with. This has received Acked-by's from both GLIBC and Linux kernel >> developers and no reservations or Nacks from anyone. >> >> Arnd, we seem to have consensus on the patch below. Is this something >> you could take and apply to your tree? >> > > I don't mind taking it, but it may be better to use the > powerpc tree if that is where it's actually being used. So this is not a powerpc only patch, but we may be the first arch to use it. Szabolcs mentioned that aarch64 was pretty quickly filling up their AT_HWCAP2 and that they will eventually require using AT_HWCAP3 as well. If you still think this should go through the powerpc tree, I can check on that. Peter
Peter Bergner <bergner@linux.ibm.com> writes: > On 2/15/24 2:16 AM, Arnd Bergmann wrote: >> On Wed, Feb 14, 2024, at 23:34, Peter Bergner wrote: >>> The powerpc toolchain keeps a copy of the HWCAP bit masks in our TCB for fast >>> access by the __builtin_cpu_supports built-in function. The TCB space for >>> the HWCAP entries - which are created in pairs - is an ABI extension, so >>> waiting to create the space for HWCAP3 and HWCAP4 until we need them is >>> problematical. Define AT_HWCAP3 and AT_HWCAP4 in the generic uapi header >>> so they can be used in glibc to reserve space in the powerpc TCB for their >>> future use. >>> >>> I scanned through the Linux and GLIBC source codes looking for unused AT_* >>> values and 29 and 30 did not seem to be used, so they are what I went >>> with. This has received Acked-by's from both GLIBC and Linux kernel >>> developers and no reservations or Nacks from anyone. >>> >>> Arnd, we seem to have consensus on the patch below. Is this something >>> you could take and apply to your tree? >>> >> >> I don't mind taking it, but it may be better to use the >> powerpc tree if that is where it's actually being used. > > So this is not a powerpc only patch, but we may be the first arch > to use it. Szabolcs mentioned that aarch64 was pretty quickly filling > up their AT_HWCAP2 and that they will eventually require using AT_HWCAP3 > as well. If you still think this should go through the powerpc tree, > I can check on that. I'm happy to take it with Arnd's ack. I trimmed up the commit message a bit, see below. cheers Author: Peter Bergner <bergner@linux.ibm.com> AuthorDate: Wed Feb 14 16:34:06 2024 -0600 Commit: Michael Ellerman <mpe@ellerman.id.au> CommitDate: Fri Feb 16 12:42:59 2024 +1100 uapi/auxvec: Define AT_HWCAP3 and AT_HWCAP4 aux vector, entries The powerpc toolchain keeps a copy of the HWCAP bit masks in the TCB for fast access by the __builtin_cpu_supports() built-in function. The TCB space for the HWCAP entries - which are created in pairs - is an ABI extension, so waiting to create the space for HWCAP3 and HWCAP4 until they are needed is problematic. Define AT_HWCAP3 and AT_HWCAP4 in the generic uapi header so they can be used in glibc to reserve space in the powerpc TCB for their future use. I scanned through the Linux and GLIBC source codes looking for unused AT_* values and 29 and 30 did not seem to be used, so they are what I went with. Signed-off-by: Peter Bergner <bergner@linux.ibm.com> Acked-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> Acked-by: Nicholas Piggin <npiggin@gmail.com> Acked-by: Szabolcs Nagy <szabolcs.nagy@arm.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/a406b535-dc55-4856-8ae9-5a063644a1af@linux.ibm.com
On 2/15/24 7:49 PM, Michael Ellerman wrote: > Peter Bergner <bergner@linux.ibm.com> writes: >> On 2/15/24 2:16 AM, Arnd Bergmann wrote: >>> On Wed, Feb 14, 2024, at 23:34, Peter Bergner wrote: >>>> Arnd, we seem to have consensus on the patch below. Is this something >>>> you could take and apply to your tree? >>>> >>> >>> I don't mind taking it, but it may be better to use the >>> powerpc tree if that is where it's actually being used. >> >> So this is not a powerpc only patch, but we may be the first arch >> to use it. Szabolcs mentioned that aarch64 was pretty quickly filling >> up their AT_HWCAP2 and that they will eventually require using AT_HWCAP3 >> as well. If you still think this should go through the powerpc tree, >> I can check on that. > > I'm happy to take it with Arnd's ack. > > I trimmed up the commit message a bit, see below. Perfect. Thanks everyone! Peter
On Wed, 14 Feb 2024 16:34:06 -0600, Peter Bergner wrote: > Changes from v1: > - Add Acked-by lines. > > The powerpc toolchain keeps a copy of the HWCAP bit masks in our TCB for fast > access by the __builtin_cpu_supports built-in function. The TCB space for > the HWCAP entries - which are created in pairs - is an ABI extension, so > waiting to create the space for HWCAP3 and HWCAP4 until we need them is > problematical. Define AT_HWCAP3 and AT_HWCAP4 in the generic uapi header > so they can be used in glibc to reserve space in the powerpc TCB for their > future use. > > [...] Applied to powerpc/next. [1/1] uapi/auxvec: Define AT_HWCAP3 and AT_HWCAP4 aux vector, entries https://git.kernel.org/powerpc/c/3281366a8e79a512956382885091565db1036b64 cheers
diff --git a/include/uapi/linux/auxvec.h b/include/uapi/linux/auxvec.h index 6991c4b8ab18..cc61cb9b3e9a 100644 --- a/include/uapi/linux/auxvec.h +++ b/include/uapi/linux/auxvec.h @@ -32,6 +32,8 @@ #define AT_HWCAP2 26 /* extension of AT_HWCAP */ #define AT_RSEQ_FEATURE_SIZE 27 /* rseq supported feature size */ #define AT_RSEQ_ALIGN 28 /* rseq allocation alignment */ +#define AT_HWCAP3 29 /* extension of AT_HWCAP */ +#define AT_HWCAP4 30 /* extension of AT_HWCAP */ #define AT_EXECFN 31 /* filename of program */