| Message ID | 20240906-arm64-elf-hwcap3-v1-0-8df1a5e63508@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: Add infrastructure for use of AT_HWCAP3 | expand |
On Fri, Sep 06, 2024 at 12:05:23AM +0100, Mark Brown wrote: > Since arm64 has now used all of AT_HWCAP2 it needs to either start using > AT_HWCAP3 (which was recently added for PowerPC) or start allocating > bits 32..61 of AT_HWCAP first. Those are documented in elf_hwcaps.rst > as unused and in uapi/asm/hwcap.h as unallocated for potential use by > libc, glibc does currently use bits 62 and 63. This series has the code > for enabling AT_HWCAP3 as a reference. > > We will at some point need to bite this bullet but we need to decide if > it's now or later. Given that we used the high bits of AT_HWCAP2 first > and AT_HWCAP3 is already defined it feels like that might be people's > preference, in order to minimise churn in serieses adding new HWCAPs > it'd be good to get consensus if that's the case or not. Since the arm64 ABI documents that only bits 62 and 63 from AT_HWCAP are reserved for glibc, I think we should start using the remaining 30 bits of AT_HWCAP first before going for AT_HWCAP3. I'm sure we'll go through them quickly enough, so these two patches will have to be merged at some point. We'll need an Ack from the (arm64) glibc people on the GCS patch series if we are going for bits 32+ in AT_HWCAP.
On Thu, Sep 12, 2024 at 05:45:45PM +0100, Catalin Marinas wrote: > On Fri, Sep 06, 2024 at 12:05:23AM +0100, Mark Brown wrote: > > We will at some point need to bite this bullet but we need to decide if > > it's now or later. Given that we used the high bits of AT_HWCAP2 first > > and AT_HWCAP3 is already defined it feels like that might be people's > > preference, in order to minimise churn in serieses adding new HWCAPs > > it'd be good to get consensus if that's the case or not. > Since the arm64 ABI documents that only bits 62 and 63 from AT_HWCAP are > reserved for glibc, I think we should start using the remaining 30 bits > of AT_HWCAP first before going for AT_HWCAP3. I'm sure we'll go through > them quickly enough, so these two patches will have to be merged at some > point. That does seem like the easiest path for everyone, assuming that there hasn't been any usage of the remaining spare bits we weren't aware of. > We'll need an Ack from the (arm64) glibc people on the GCS patch series > if we are going for bits 32+ in AT_HWCAP. Yup, hopefully Yuri or Wilco can confirm prior to reposting. It does seem like it'd be good for glibc to add whatever support is needed for HWCAP3/4 now anyway so that whenever we do burn through the remaining bits on AT_HWCAP there's less friction as we start using them.
Since arm64 has now used all of AT_HWCAP2 it needs to either start using AT_HWCAP3 (which was recently added for PowerPC) or start allocating bits 32..61 of AT_HWCAP first. Those are documented in elf_hwcaps.rst as unused and in uapi/asm/hwcap.h as unallocated for potential use by libc, glibc does currently use bits 62 and 63. This series has the code for enabling AT_HWCAP3 as a reference. We will at some point need to bite this bullet but we need to decide if it's now or later. Given that we used the high bits of AT_HWCAP2 first and AT_HWCAP3 is already defined it feels like that might be people's preference, in order to minimise churn in serieses adding new HWCAPs it'd be good to get consensus if that's the case or not. Signed-off-by: Mark Brown <broonie@kernel.org> --- Mark Brown (2): binfmt_elf: Wire up AT_HWCAP3 at AT_HWCAP4 arm64: Support AT_HWCAP3 Documentation/arch/arm64/elf_hwcaps.rst | 6 +++--- arch/arm64/include/asm/cpufeature.h | 3 ++- arch/arm64/include/asm/hwcap.h | 6 +++++- arch/arm64/include/uapi/asm/hwcap.h | 4 ++++ arch/arm64/kernel/cpufeature.c | 6 ++++++ fs/binfmt_elf.c | 6 ++++++ fs/binfmt_elf_fdpic.c | 6 ++++++ fs/compat_binfmt_elf.c | 15 +++++++++++++++ 8 files changed, 47 insertions(+), 5 deletions(-) --- base-commit: 7c626ce4bae1ac14f60076d00eafe71af30450ba change-id: 20240905-arm64-elf-hwcap3-7709c5593d34 Best regards,