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 64DF3C56208 for ; Thu, 6 Aug 2026 11:26:23 +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=DT8B2LO3ZdXVJlIid+w8XqcO8fdk7HdsKtLWhAIf06A=; b=qBY0OzM5SuwkWE4wpquFrB7w7h NX0tjDPmj78A5y05rD7Qgimtez6s75M9mtnw9Ieu+h14LbshXoxJF9BDrmUlfjx+9F05fpg26zEEa 9r9OmGROXuMGq1qjP3iP/x8G4NX4g5cd1OEWA1Rs5zpJp4XRNDZ0DNDTXX3JUM8o4lrmkMQQj2lEX OuWnufTYy7qEWvVzvo5Uy5E4kAz+dGL2zxJtpd0gw8zX6eLHq0q+KZuKgyAm504rsJlUevGiauJh+ TrRsMG2LPa1Bgvtd87IpcsG83knH+Vf2i/MhMdStTSbyI5CJTVN7Q55Mxu+t47YYwMPy0NeE3cQKE H1ONDpFA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.99.1 #2 (Red Hat Linux)) id 1wrwEm-00000005e77-3sdQ; Thu, 06 Aug 2026 11:26:12 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.99.1 #2 (Red Hat Linux)) id 1wrwEk-00000005e6e-3dF1 for linux-arm-kernel@lists.infradead.org; Thu, 06 Aug 2026 11:26:10 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 330D243939; Thu, 6 Aug 2026 11:26:10 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 27C2E1F000E9; Thu, 6 Aug 2026 11:26:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786015570; bh=DT8B2LO3ZdXVJlIid+w8XqcO8fdk7HdsKtLWhAIf06A=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=VY4MFbLqKm6tyjXeoDAWMPpoRIw5LKmZF3+M10gkXz7OZ+aOzp8W5PAb9jkb8BqEr lzNg/2ITl4FuLmQH6orC2YrqRR4sbs6ginKtehvLq/4tcsiNORvy31drGFpjjDpaa+ VQ0RsBD7I4ykWdKClqweo0utXS8sc4oTZ5cccLprymE45QnVTnN3lQ4+R3N6yEU1In cL7JoWYr92didjgKIFFuHuZpjC4XCiEdbGtCS8tjAfbada4lTFD/AiOblgDAQr9HiT wilTJaKMpnyFsrOZeU82RWBoWPnzAhROmW3BIvjoAqn6a0clFPr70jyXPlUN/4bDLq K2Om/kNk5ZH0A== Date: Thu, 6 Aug 2026 12:26:04 +0100 From: Will Deacon To: Linu Cherian Cc: Catalin Marinas , Ryan Roberts , Kevin Brodsky , Anshuman Khandual , Suzuki K Poulose , Mark Rutland , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Gavin Shan Subject: Re: [PATCH v4 6/6] arm64: cpufeature: Detect BBML3 based on ID_AA64MMFR2_EL1.BBM Message-ID: References: <20260723044034.2983651-1-linu.cherian@arm.com> <20260723044034.2983651-7-linu.cherian@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 05, 2026 at 02:50:55PM +0530, Linu Cherian wrote: > On Tue, Aug 04, 2026 at 02:51:28PM +0100, Will Deacon wrote: > > On Mon, Aug 03, 2026 at 09:22:02AM +0530, Linu Cherian wrote: > > > On Fri, Jul 31, 2026 at 04:13:20PM +0100, Will Deacon wrote: > > > > On Thu, Jul 23, 2026 at 10:10:33AM +0530, Linu Cherian wrote: > > > > > Add ID_AA64MMFR2_EL1.BBM based BBML3 feature detection in > > > > > cpu_supports_bbml3() so that cpus with the feature would > > > > > not have to be added into MIDR based supports_bbml3_list. > > > > > > > > > > Reviewed-by: Gavin Shan > > > > > Reviewed-by: Anshuman Khandual > > > > > Signed-off-by: Linu Cherian > > > > > --- > > > > > arch/arm64/kernel/cpufeature.c | 17 +++++++++-------- > > > > > 1 file changed, 9 insertions(+), 8 deletions(-) > > > > > > > > > > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c > > > > > index 896bafdb00b1..dbd7d187520c 100644 > > > > > --- a/arch/arm64/kernel/cpufeature.c > > > > > +++ b/arch/arm64/kernel/cpufeature.c > > > > > @@ -2133,6 +2133,12 @@ static bool hvhe_possible(const struct arm64_cpu_capabilities *entry, > > > > > > > > > > bool cpu_supports_bbml3(void) > > > > > { > > > > > + u64 mmfr2; > > > > > + > > > > > + mmfr2 = __read_sysreg_by_encoding(SYS_ID_AA64MMFR2_EL1); > > > > > + if (SYS_FIELD_GET(ID_AA64MMFR2_EL1, BBM, mmfr2) >= ID_AA64MMFR2_EL1_BBM_3) > > > > > + return true; > > > > > > > > This is a bit of a nit, but I think it would be more consistent to use > > > > has_cpuid_feature() here instead of __read_sysreg_by_encoding(), similarly > > > > to how we handle kpti in unmap_kernel_at_el0() (which also has both an > > > > ID register field and a list of MIDRs). > > > > > > force_pte_mapping required by map_mem(during early boot) needs > > > cpu_supports_bbml3 check and cpu features/capabilities are not > > > initialized by that time. Should i add a comment there to clarify this ? > > > > It looks to me like has_cpuid_feature() will call > > __read_sysreg_by_encoding() under the hood for SCOPE_LOCAL_CPU. > > > > What am I missing? > > Below is my understanding. Correct me if i am wrong. > has_cpuid_feature depends on struct arm64_cpu_capabilities *entry. > Inorder to derive *entry from a capability ID, cpucap_ptrs should be > in initialized state and that wont be the case when force_pte_mapping > invokes cpu_supports_bbml3. Ah, I see what you mean. We do have a 'struct arm64_cpu_capabilities' entry for this in arm64_features[] but fishing that out is grotty at the setup_arch() stage. Will