On 2024/12/3 17:38, Marc Zyngier wrote:
> On Mon, 02 Dec 2024 13:55:01 +0000,
> Yicong Yang <yangyicong@xxxxxxxxxx> wrote:
>>
>> From: Yicong Yang <yangyicong@xxxxxxxxxxxxx>
>>
>> Armv8.7 introduces single-copy atomic 64-byte loads and stores
>> instructions and its variants named under FEAT_{LS64, LS64_V,
>> LS64_ACCDATA}. 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 HWCAP
>> and cpuinfo
>>
>> Signed-off-by: Yicong Yang <yangyicong@xxxxxxxxxxxxx>
>> ---
>> Documentation/arch/arm64/booting.rst | 28 ++++++++++
>> Documentation/arch/arm64/elf_hwcaps.rst | 9 ++++
>> arch/arm64/include/asm/hwcap.h | 3 ++
>> arch/arm64/include/uapi/asm/hwcap.h | 3 ++
>> arch/arm64/kernel/cpufeature.c | 70 ++++++++++++++++++++++++-
>> arch/arm64/kernel/cpuinfo.c | 3 ++
>> arch/arm64/tools/cpucaps | 3 ++
>> 7 files changed, 118 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/arch/arm64/booting.rst b/Documentation/arch/arm64/booting.rst
>> index 3278fb4bf219..c35cfe9da501 100644
>> --- a/Documentation/arch/arm64/booting.rst
>> +++ b/Documentation/arch/arm64/booting.rst
>> @@ -449,6 +449,34 @@ Before jumping into the kernel, the following conditions must be met:
>>
>> - HFGWTR_EL2.nGCS_EL0 (bit 52) must be initialised to 0b1.
>>
>> + For CPUs support for 64-byte loads and stores without status (FEAT_LS64):
>> +
>> + - 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):
>> +
>> + - If the kernel is entered at EL1 and EL2 is present:
>> +
>> + - HCRX_EL2.EnASR (bit 2) must be initialised to 0b1.
>> +
>> + For CPUs support for 64-byte EL0 stores with status (FEAT_LS64_ACCDATA):
>> +
>> + - If EL3 is present:
>> +
>> + - SCR_EL3.EnAS0 (bit 36) must be initialised to 0b1.
>> +
>> + - SCR_EL3.ADEn (bit 37) must be initialised to 0b1.
>> +
>> + - If the kernel is entered at EL1 and EL2 is present:
>> +
>> + - HCRX_EL2.EnAS0 (bit 0) must be initialised to 0b1.
>> +
>> + - HFGRTR_EL2.nACCDATA_EL1 (bit 50) must be initialised to 0b1.
>> +
>> + - HFGWTR_EL2.nACCDATA_EL1 (bit 50) 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 2ff922a406ad..6cb2594f0803 100644
>> --- a/Documentation/arch/arm64/elf_hwcaps.rst
>> +++ b/Documentation/arch/arm64/elf_hwcaps.rst
>> @@ -372,6 +372,15 @@ 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.
>> +
>> +HWCAP3_LS64_ACCDATA
>> + Functionality implied by ID_AA64ISAR1_EL1.LS64 == 0b0011.
>> +
>
> I don't mind the two others, but I seriously question exposing ST64BV0
> to userspace. How is ACCDATA_EL1 populated? How is it context-switched?
>
> As it stands, this either does the wrong thing by always having the
> low 32bit set to an UNKNOWN value, or actively leaks kernel data.
> TBH, I don't see it being usable in practice (the more I read this
> part of the architecture, the more broken it looks).
>
you're right, expose this LS64_ACCDATA alone to userspace won't make it
usable since ACCDATA_EL1 cannot be accessed from EL0. will drop this at
this stage.
Thanks.
