Re: [PATCH v4 5/7] arm64: Add support for FEAT_{LS64, LS64_V}

[Will Deacon <will@kernel.org>]

On Tue, Jul 15, 2025 at 04:13:54PM +0800, Yicong Yang wrote:
> From: Yicong Yang <yangyicong@hisilicon.com>
> 
> Armv8.7 introduces single-copy atomic 64-byte loads and stores
> instructions and its variants named under FEAT_{LS64, LS64_V}.
> These features are identified by ID_AA64ISAR1_EL1.LS64 and the
> use of such instructions in userspace (EL0) can be trapped. In
> order to support the use of corresponding instructions in userspace:
> - Make ID_AA64ISAR1_EL1.LS64 visbile to userspace
> - Add identifying and enabling in the cpufeature list
> - Expose these support of these features to userspace through HWCAP3
>   and cpuinfo
> 
> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
> ---
>  Documentation/arch/arm64/booting.rst    | 12 ++++++
>  Documentation/arch/arm64/elf_hwcaps.rst |  6 +++
>  arch/arm64/include/asm/hwcap.h          |  2 +
>  arch/arm64/include/uapi/asm/hwcap.h     |  2 +
>  arch/arm64/kernel/cpufeature.c          | 51 +++++++++++++++++++++++++
>  arch/arm64/kernel/cpuinfo.c             |  2 +
>  arch/arm64/tools/cpucaps                |  2 +
>  7 files changed, 77 insertions(+)
> 
> diff --git a/Documentation/arch/arm64/booting.rst b/Documentation/arch/arm64/booting.rst
> index ee9b790c0d72..837823d49212 100644
> --- a/Documentation/arch/arm64/booting.rst
> +++ b/Documentation/arch/arm64/booting.rst
> @@ -483,6 +483,18 @@ Before jumping into the kernel, the following conditions must be met:
>  
>     - MDCR_EL3.TPM (bit 6) must be initialized to 0b0
>  
> +  For CPUs support for 64-byte loads and stores without status (FEAT_LS64):

nit: I think you're missing a word ("For CPUs with support ...").

> +
> +  - If the kernel is entered at EL1 and EL2 is present:
> +
> +    - HCRX_EL2.EnALS (bit 1) must be initialised to 0b1.
> +
> +  For CPUs support for 64-byte loads and stores with status (FEAT_LS64_V):

Same here, but also FEAT_LS64_V only applies to stores so no need to
mention loads.

> +
> +  - If the kernel is entered at EL1 and EL2 is present:
> +
> +    - HCRX_EL2.EnASR (bit 2) must be initialised to 0b1.
> +
>  The requirements described above for CPU mode, caches, MMUs, architected
>  timers, coherency and system registers apply to all CPUs.  All CPUs must
>  enter the kernel in the same exception level.  Where the values documented
> diff --git a/Documentation/arch/arm64/elf_hwcaps.rst b/Documentation/arch/arm64/elf_hwcaps.rst
> index 69d7afe56853..9e6db258ff48 100644
> --- a/Documentation/arch/arm64/elf_hwcaps.rst
> +++ b/Documentation/arch/arm64/elf_hwcaps.rst
> @@ -435,6 +435,12 @@ HWCAP2_SME_SF8DP4
>  HWCAP2_POE
>      Functionality implied by ID_AA64MMFR3_EL1.S1POE == 0b0001.
>  
> +HWCAP3_LS64
> +    Functionality implied by ID_AA64ISAR1_EL1.LS64 == 0b0001.
> +
> +HWCAP3_LS64_V
> +    Functionality implied by ID_AA64ISAR1_EL1.LS64 == 0b0010.

Given that these instructions only work on IMPLEMENTATION DEFINED memory
locations and aren't guaranteed to generate an abort if used elsewhere,
how is userspace supposed to know what to do with them?

As it stands, exposing the feature blindly feels like a bad idea to me.
Surely there needs to be a way for userspace to either probe or request
memory that supports the instructions? We should also make sure we
handle the abort properly if it occurs and presumably deliver a SIGBUS.

Will