[PATCH v2 1/4] arm64/cpufeature: Store elf_hwcaps as an array rather than unsigned long

[Will Deacon]

On Mon, Jun 20, 2022 at 01:54:48PM +0100, Mark Brown wrote:
> When we added support for AT_HWCAP2 we took advantage of the fact that we
> have limited hwcaps to the low 32 bits and stored it along with AT_HWCAP
> in a single unsigned integer. Thanks to the ever expanding capabilities of
> the architecture we have now allocated all 64 of the bits in an unsigned
> long so in preparation for adding more hwcaps convert elf_hwcap to be an
> array instead. There should be no functional change from this patch.
> 
> Signed-off-by: Mark Brown <broonie at kernel.org>
> ---
>  arch/arm64/include/asm/cpufeature.h |  2 ++
>  arch/arm64/include/asm/hwcap.h      |  4 +++-
>  arch/arm64/kernel/cpufeature.c      | 22 +++++++++++++++-------
>  3 files changed, 20 insertions(+), 8 deletions(-)

I would like to see an Ack on this series from the libc side (i.e.
Szabolcs) before we extend the ABI. Have any other architectures used
HWCAP3?

> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index 14a8f3d93add..84756c660b5e 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -11,6 +11,8 @@
>  #include <asm/hwcap.h>
>  #include <asm/sysreg.h>
>  
> +/* Note that bits 62 and 63 of each AT_HWCAP are reserved */

Can you expand a bit on this comment, please? It's not clear who has
reserved those bits (e.g. kernel or userspace) and why having two bit
reserved means we are limited to 32 instead of 62 bits.

> +#define CPU_FEATURES_PER_HWCAP	32
>  #define MAX_CPU_FEATURES	64
>  #define cpu_feature(x)		KERNEL_HWCAP_ ## x
>  
> diff --git a/arch/arm64/include/asm/hwcap.h b/arch/arm64/include/asm/hwcap.h
> index aa443d8f8cfb..e0054c7b3a98 100644
> --- a/arch/arm64/include/asm/hwcap.h
> +++ b/arch/arm64/include/asm/hwcap.h
> @@ -41,6 +41,8 @@
>  #ifndef __ASSEMBLY__
>  #include <linux/log2.h>
>  
> +#define KHWCAP_OFFSET(n)		((n - 1) * CPU_FEATURES_PER_HWCAP)
> +
>  /*
>   * For userspace we represent hwcaps as a collection of HWCAP{,2}_x bitfields
>   * as described in uapi/asm/hwcap.h. For the kernel we represent hwcaps as
> @@ -85,7 +87,7 @@
>  #define KERNEL_HWCAP_PACA		__khwcap_feature(PACA)
>  #define KERNEL_HWCAP_PACG		__khwcap_feature(PACG)
>  
> -#define __khwcap2_feature(x)		(const_ilog2(HWCAP2_ ## x) + 32)
> +#define __khwcap2_feature(x)		(const_ilog2(HWCAP2_ ## x) + KHWCAP_OFFSET(2))
>  #define KERNEL_HWCAP_DCPODP		__khwcap2_feature(DCPODP)
>  #define KERNEL_HWCAP_SVE2		__khwcap2_feature(SVE2)
>  #define KERNEL_HWCAP_SVEAES		__khwcap2_feature(SVEAES)
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 8d88433de81d..1a8f60a6661e 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -91,7 +91,7 @@
>  #include <asm/virt.h>
>  
>  /* Kernel representation of AT_HWCAP and AT_HWCAP2 */
> -static unsigned long elf_hwcap __read_mostly;
> +static unsigned long elf_hwcap[MAX_CPU_FEATURES / CPU_FEATURES_PER_HWCAP] __read_mostly;

I can't help but think this would be neater as an explicit bitmap
(i.e. DECLARE_BITMAP).

Will