From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 46949459AC4 for ; Thu, 6 Aug 2026 11:26:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786015571; cv=none; b=Du2Gc1jMHARB/3EC+xgALVua0tyUkKMAvrdEWyVy5B+QJBh1/quUx6egzZtL13U8xjrhi7PA8OwQ2dSY+5IuddwUU2BtNJX3YhiaKgMAL1KfXAvDeecP5fzpkRcdfu6+NumKmRqTVnxYR6ySuMowEA/TZ5A8iNFMsCJksJ+4scs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786015571; c=relaxed/simple; bh=YKcD089geMHiRhAz6RxHOT1UFC3Pmyq2maMkFlFwzfk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ODICyuBunPtR3MPQLQgrMmN7ZzIyJumbkdhE12rlD2/lamWx19wD19OHPqooP2xOD4D7dBCXwb586wyBUQgJZlVCmoRUYja+RGx12c/vn0V0kZbc4sqe9uXALPTAx2VC6qJpMFtM4UdXP6o2lRjJDU2z0Ae5ntAFveSOUx/flOY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VY4MFbLq; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VY4MFbLq" 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> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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