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 DBE28C531DC for ; Tue, 20 Aug 2024 16:19:36 +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:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From: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=iBDwEVGdu9KxVi1HABA+7XkFaO6N0af7NBw4YlTkfK4=; b=O6LsG8y7m0IDEV3R6oBs8I5cW4 3iT3AlTRKSNiNLYznlCWKV08/FeX1bCUdzhnmIk5tfxqjNPqW2jhPWoZ/neylUVOIu6NVsA/mT2PF laA88SWFkKbhAlvIvNE6xlM5BC7bixYupcFVMsx4Ym6rabMXFqTg9mc7g1sUskzb+G7i+4QsNj+QR HweyaG4iiWAwyDV7NRCUPdDs4hhw4tL53dWmzkXMawcvrVvamY4UtHs+fV8uApss4zasZ5ym5LY6/ AUGw3cylYfpmFIOHCd9DUSH8L6JfXITO9PAFvLD9NMs99qbl9hpYyw9nWjlC2BowJFLJe16YsqX1T DSCNmHoA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sgRZm-00000005yHZ-2dJ9; Tue, 20 Aug 2024 16:19:18 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sgRZ4-00000005y5m-2NIY for linux-arm-kernel@lists.infradead.org; Tue, 20 Aug 2024 16:18:36 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 592EECE094C; Tue, 20 Aug 2024 16:18:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5C44EC4AF14; Tue, 20 Aug 2024 16:18:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724170709; bh=C6obJbOv0nVGmNR2gXLVl3CGD9mbtfk9IkHNyA3m9O8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=FqOzorpclsjUezoJ1rlg7/BSu2JCu/NWuVH++HpqsY5Y5GHMdpIS8PtyUqFNS7M4J B6DXRNrWFTGUJvM7wZ8JHXYKdxbW4ZCcReeKtj7WiiIeIG3jSHrRaq0QKUcYJMSF4g 1/m8RIS46T4VBc2+l8MZCTowWKBHx1z32LCgDL7pgV+mAPZ7HhgX3UgTv4eyiVOYHE TlTiICK8n6ybk8E1EzkF5TqbfL5/bkZg3b0EUNPfnekTc51X82NdVa2HG7LNF4GLHU r1k9iO6aD394kD0WH4mbQtgo42mbYY2mHovjqiZhQ3Nn0/v67xlipRdNhURf5kZt4m 8vernuLgXN4qA== Date: Tue, 20 Aug 2024 17:18:22 +0100 From: Will Deacon To: Yicong Yang Cc: catalin.marinas@arm.com, maz@kernel.org, mark.rutland@arm.com, linux-arm-kernel@lists.infradead.org, oliver.upton@linux.dev, broonie@kernel.org, ryan.roberts@arm.com, linuxarm@huawei.com, jonathan.cameron@huawei.com, shameerali.kolothum.thodi@huawei.com, prime.zeng@hisilicon.com, xuwei5@huawei.com, wangkefeng.wang@huawei.com, yangyicong@hisilicon.com Subject: Re: [PATCH v2 1/2] arm64: Add support for FEAT_HAFT Message-ID: <20240820161822.GC28750@willie-the-truck> References: <20240814092333.7727-1-yangyicong@huawei.com> <20240814092333.7727-2-yangyicong@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240814092333.7727-2-yangyicong@huawei.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240820_091834_972883_92EAB9E5 X-CRM114-Status: GOOD ( 32.96 ) 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 Wed, Aug 14, 2024 at 05:23:32PM +0800, Yicong Yang wrote: > From: Yicong Yang > > Armv8.9/v9.4 introduces the feature Hardware managed Access Flag > for Table descriptors (FEAT_HAFT). The feature is indicated by > ID_AA64MMFR1_EL1.HAFDBS == 0b0011 and can be enabled by > TCR2_EL1.HAFT so it has a dependency on FEAT_TCR2. > > This patch adds the Kconfig for FEAT_HAFT and support detecting > and enabling the feature. > > Signed-off-by: Yicong Yang > --- > arch/arm64/Kconfig | 19 +++++++++++++++++++ > arch/arm64/kernel/cpufeature.c | 26 ++++++++++++++++++++++++++ > arch/arm64/tools/cpucaps | 1 + > arch/arm64/tools/sysreg | 1 + > 4 files changed, 47 insertions(+) > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index a2f8ff354ca6..869792458a23 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -2137,6 +2137,25 @@ config ARM64_EPAN > if the cpu does not implement the feature. > endmenu # "ARMv8.7 architectural features" > > +menu "ARMv8.9 architectural features" > + > +config ARM64_HAFT > + bool "Support for Hardware managed Access Flag for Table Descriptor" > + depends on ARM64_HW_AFDBM > + default y > + help > + The ARMv8.9/ARMv9.5 introduces the feature Hardware managed Access > + Flag for Table descriptors. When enabled an architectural executed > + memory access will update the Access Flag in each Table descriptor > + which is accessed during the translation table walk and for which > + the Access Flag is 0. The Access Flag of the Table descriptor use > + the same bit of PTE_AF. > + > + The feature will only be enabled if all the CPUs in the system > + support this feature. If unsure, say Y. > + > +endmenu # "ARMv8.9 architectural features" > + > config ARM64_SVE > bool "ARM Scalable Vector Extension support" > default y > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c > index 646ecd3069fd..ed4c968be935 100644 > --- a/arch/arm64/kernel/cpufeature.c > +++ b/arch/arm64/kernel/cpufeature.c > @@ -2044,6 +2044,17 @@ static bool has_hw_dbm(const struct arm64_cpu_capabilities *cap, > > #endif > > +#if CONFIG_ARM64_HAFT > + > +static void cpu_enable_haft(struct arm64_cpu_capabilities const *cap) > +{ > + sysreg_clear_set_s(SYS_TCR2_EL1, 0, TCR2_EL1x_HAFT); > + isb(); > + local_flush_tlb_all(); > +} As this isn't a per-TTBR enable, should we be initialising the kernel table entries in TTBR1 as YOUNG to avoid potential races with the hardware update? It looks like the bit is ignored on CPUs without HAFT, so we can just do this unconditionally. At the very least, we should be able to enable HAFT in __cpu_setup(), like we do for HA. > +#endif > + > #ifdef CONFIG_ARM64_AMU_EXTN > > /* > @@ -2580,6 +2591,21 @@ static const struct arm64_cpu_capabilities arm64_features[] = { > .cpus = &dbm_cpus, > ARM64_CPUID_FIELDS(ID_AA64MMFR1_EL1, HAFDBS, DBM) > }, > +#endif > +#ifdef CONFIG_ARM64_HAFT > + { > + .desc = "Hardware managed Access Flag for Table Descriptor", > + /* > + * Contrary to the page/block access flag, the table access flag > + * cannot be emulated in software (no access fault will occur). > + * Therefore mandate that all CPUs have FEAT_HAFT. > + */ It's a bit of a pity that we can't handle this mismatch. After all, access flag data is imprecise (unlike the dirty bit) and so you could envisage a mechanism for falling back to leaf-level AF at runtime rather than refusing to online a CPU. Of course, it's hard to tell whether this really matters until we see what people try to glue together. Will