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
