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

[Will Deacon <will@kernel.org>]

On Tue, Sep 09, 2025 at 09:48:04AM +0800, Yicong Yang wrote:
> On 2025/9/8 20:01, Will Deacon wrote:
> > On Tue, Jul 15, 2025 at 04:13:54PM +0800, Yicong Yang wrote:
> >> 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?
> > 
> 
> per ARM DDI0487 L.b section C3.2.6,
> 
>   When the instructions access a memory type that is not one of the following,
>   a data abort for unsupported Exclusive or atomic access is generated...

That's about the memory _type_. I'm talking about a supported memory type
(e.g. writeback cacheable) but when the physical location doesn't support
the instruction. That's captured a little later in the same section:

  | If the target memory location does not support the LD64B or ST64B
  | instructions, then one of the following behaviors occurs:
  |  * A stage 1 Data Abort, reported using the DFSC code of 0b110101,
  |    is generated.
  |  * The instruction performs the memory accesses, but the accesses
  |    are not single-copy atomic above the byte level

and I think that's a bad interface to expose blindly to userspace solely
as a boolean hwcap.

Will