From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 627A4D4979A for ; Tue, 3 Dec 2024 09:40:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=GiJfyyOkSJtbsYCACJSFjHTmc4p3yf81QSkKTWd2Y14=; b=xg262jUQvYaEhycyaTdZPi/DwP S2P/Ose390dw3OkTvNkadCiW6TJJWVo9BymltfFhvLzpxUtIkxwjyCspiIyMkP/CL148v2KM80DUN tzg6WWWjRRIyvN1jZkkAfGtHwrGAp84UcycDjv9Kf9F/vfssR/Z2C6ujzbhEQFE7RNBqlna4tYNV8 jmW4EZ/78gkt/zy1bX5GD8+1O0tFWPfnLM994onv90LR4iSo98gZBcPHXZUeEy7EF3yjQ0ugP6eFk fxKYPmu1PWYLg03Tkkjt7GGriCQsSmHZ7yRpBmyszFztmWuDS8MSz/rvFvAGdXnKP3DuiLlWtcp/w 70UqIiMg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tIPOE-00000008vqY-2iPq; Tue, 03 Dec 2024 09:40:18 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tIPMK-00000008vH0-3j2T for linux-arm-kernel@lists.infradead.org; Tue, 03 Dec 2024 09:38:22 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 66AAA5C6B6B; Tue, 3 Dec 2024 09:37:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 10E4BC4CECF; Tue, 3 Dec 2024 09:38:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1733218700; bh=RTXFdOfvmcVJEudvLjpK3I/u/d16/ZYqKz3aDspgte4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=uUogFoHRb3G4sMDu3dV2XK8agbhd4zna9SiC2u7Utx8yu2MzsTuHrQbx3HRKuhvXK aXKwhwMrzM8myDdyyJosLOfHvkHj8A+khvy9tEDaeWI+x0BWCXVZPFmkXuBZQIAdng 6o9+iuwjqdj3Vczkx0RSnoXEYxFJ3RQB7mH/uXzROPprOOyuZTmQQa3Tb7R8WqCpUw xbugPZ3LRpkUNtbWIKTGwLBWhP84osaEBAerCJi5cLN99eMluvjLVhy67iSwQwRjFK drFAHRRsTGY8m8DwAI/LEOlAfNJyZCEQ7m/bfKmlh4H7iZH6mlncWDn+jK0/t8K2S3 lP03tA8tHkPZg== Received: from [104.132.45.111] (helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1tIPMH-0002Ka-J3; Tue, 03 Dec 2024 09:38:17 +0000 Date: Tue, 03 Dec 2024 09:38:16 +0000 Message-ID: <87mshdrtrr.wl-maz@kernel.org> From: Marc Zyngier To: Yicong Yang Cc: , , , , , , , , , , , , , , , , , Subject: Re: [PATCH 2/5] arm64: Add support for FEAT_{LS64, LS64_V, LS64_ACCDATA} In-Reply-To: <20241202135504.14252-3-yangyicong@huawei.com> References: <20241202135504.14252-1-yangyicong@huawei.com> <20241202135504.14252-3-yangyicong@huawei.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 104.132.45.111 X-SA-Exim-Rcpt-To: yangyicong@huawei.com, catalin.marinas@arm.com, will@kernel.org, oliver.upton@linux.dev, corbet@lwn.net, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, shuah@kernel.org, jonathan.cameron@huawei.com, shameerali.kolothum.thodi@huawei.com, linuxarm@huawei.com, prime.zeng@hisilicon.com, xuwei5@huawei.com, yangyicong@hisilicon.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20241203_013821_029586_2046EB70 X-CRM114-Status: GOOD ( 26.77 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, 02 Dec 2024 13:55:01 +0000, Yicong Yang wrote: > > From: Yicong Yang > > 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 > --- > 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). Thanks, M. -- Without deviation from the norm, progress is not possible.