[PATCH v4 0/6] Add BBML3 cpu feature

[PATCH v4 0/6] Add BBML3 cpu feature

[Linu Cherian]

- Patches 1, 2 and 3 adds more cpus to the bbml2_noabort 
  support list. bbml2_noabort would eventually gets renamed
  to bbml3 in a subsequent patch as they are functionally
  equivalent. 
- Patches 4, 5 & 6 introduces BBML3 cpu feature

Changelog from v3:
* In order to cover future C1-Ultra and C1-Premium cpus starting
from r1p1, replaced MIDR_REV_RANGE with MIDR_RANGE in patch 3

* Few minor fixes in comments

* Collected Reviewed-bys.

Changelog from v2:
* Added errata id to Documentation/arch/arm64/silicon-errata.rst
  in patch 3. Added comments in code related to errata as well.

* Fixed register name typo in commit message in patch 4.

* Renamed patch title in patch 5. 

* Commit message reworded in patch 6.

* No functional changes in this version.

Changelog from v1:
* Patches associated with adding cpus to BBML2_NOABORT,
  support list, were kept at bottom in v1 is now moved
  up in this version, for ease of backporting.

* Adding BBM_3 definition in sysreg moved into a separate patch

* MMFR2_ID check for BBM_3 has been changed from == BBM_3 to
  >= BBM_3, so that BBML3 cpu feature gets enabled for BBM_4 as well.

* For feature detection, MMFR2_ID check comes first followed by 
  midr check for code readability

* Errata details for C1-Ultra and C1-Premium added to commit message





Linu Cherian (6):
  arm64: cputype: Add Cortex-A520AE definitions
  arm64: cputype: Add C1-Nano definitions
  arm64: cpufeature: Extend bbml2_noabort support list
  arm64: sysreg: Add BBM_3
  arm64: cpufeature: Rename BBML2_NOABORT as BBML3
  arm64: cpufeature: Detect BBML3 based on ID_AA64MMFR2_EL1.BBM

 Documentation/arch/arm64/silicon-errata.rst |  4 ++
 arch/arm64/include/asm/cpufeature.h         |  6 +--
 arch/arm64/include/asm/cputype.h            |  4 ++
 arch/arm64/kernel/cpufeature.c              | 55 ++++++++++-----------
 arch/arm64/mm/contpte.c                     | 21 +++-----
 arch/arm64/mm/mmu.c                         | 54 ++++++++++----------
 arch/arm64/mm/proc.S                        |  4 +-
 arch/arm64/tools/cpucaps                    |  2 +-
 arch/arm64/tools/sysreg                     |  1 +
 9 files changed, 77 insertions(+), 74 deletions(-)

-- 
2.43.0

[PATCH v4 1/6] arm64: cputype: Add Cortex-A520AE definitions

[Linu Cherian]

Add cputype definitions for Cortex-A520AE.

The definition can be found in Cortex-A520AE TRM,
https://developer.arm.com/documentation/107726/0001/
as part of MIDR_EL1 bit descriptions.

This is going to be used in the bbml3 support list.

Reviewed-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Linu Cherian <linu.cherian@arm.com>
---
 arch/arm64/include/asm/cputype.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index 1b9f0cda1336..e41fae46426b 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -82,6 +82,7 @@
 #define ARM_CPU_PART_CORTEX_X1		0xD44
 #define ARM_CPU_PART_CORTEX_A510	0xD46
 #define ARM_CPU_PART_CORTEX_A520	0xD80
+#define ARM_CPU_PART_CORTEX_A520AE	0xD88
 #define ARM_CPU_PART_CORTEX_A710	0xD47
 #define ARM_CPU_PART_CORTEX_A715	0xD4D
 #define ARM_CPU_PART_CORTEX_X2		0xD48
@@ -176,6 +177,7 @@
 #define MIDR_CORTEX_X1	MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X1)
 #define MIDR_CORTEX_A510 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A510)
 #define MIDR_CORTEX_A520 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A520)
+#define MIDR_CORTEX_A520AE MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A520AE)
 #define MIDR_CORTEX_A710 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A710)
 #define MIDR_CORTEX_A715 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A715)
 #define MIDR_CORTEX_X2 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_X2)
-- 
2.43.0

[PATCH v4 2/6] arm64: cputype: Add C1-Nano definitions

[Linu Cherian]

Add cputype definitions for C1-Nano.

The definition can be found in C1-Nano TRM,
https://developer.arm.com/documentation/107753/0002
as part of MIDR_EL1 bit descriptions.

This is going to be used in the bbml3 support list.

Reviewed-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Linu Cherian <linu.cherian@arm.com>
---
 arch/arm64/include/asm/cputype.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/include/asm/cputype.h b/arch/arm64/include/asm/cputype.h
index e41fae46426b..1fa29616e586 100644
--- a/arch/arm64/include/asm/cputype.h
+++ b/arch/arm64/include/asm/cputype.h
@@ -100,6 +100,7 @@
 #define ARM_CPU_PART_CORTEX_A720AE	0xD89
 #define ARM_CPU_PART_C1_ULTRA		0xD8C
 #define ARM_CPU_PART_NEOVERSE_N3	0xD8E
+#define ARM_CPU_PART_C1_NANO		0xD8A
 #define ARM_CPU_PART_C1_PRO		0xD8B
 #define ARM_CPU_PART_C1_PREMIUM		0xD90
 
@@ -195,6 +196,7 @@
 #define MIDR_CORTEX_A720AE MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_CORTEX_A720AE)
 #define MIDR_C1_ULTRA MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_C1_ULTRA)
 #define MIDR_NEOVERSE_N3 MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_NEOVERSE_N3)
+#define MIDR_C1_NANO MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_C1_NANO)
 #define MIDR_C1_PRO MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_C1_PRO)
 #define MIDR_C1_PREMIUM MIDR_CPU_MODEL(ARM_CPU_IMP_ARM, ARM_CPU_PART_C1_PREMIUM)
 #define MIDR_THUNDERX	MIDR_CPU_MODEL(ARM_CPU_IMP_CAVIUM, CAVIUM_CPU_PART_THUNDERX)
-- 
2.43.0

[PATCH v4 3/6] arm64: cpufeature: Extend bbml2_noabort support list

[Linu Cherian]

Add below cpus to the midr list, which supports
BBML2_NOABORT.

Cortex A520(AE)
Cortex A715
Cortex A720(AE)
Cortex A725
Neoverse N3
C1-Nano
C1-Pro
C1-Ultra
C1-Premium

C1-Ultra and C1-Premium both suffer from erratum 3683289,
where Break-Before-Make must be followed to avoid a livelock.
For both CPUs, the erratum is fixed from r1p1.
Hence we do not enable BBML2_NOABORT for CPU revisions <= r1p0.

The relevant SDENs are:
* C1-Ultra: https://developer.arm.com/documentation/111077/9-00/
* C1-Premium: https://developer.arm.com/documentation/111078/9-00/

Reviewed-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Linu Cherian <linu.cherian@arm.com>
---
 Documentation/arch/arm64/silicon-errata.rst |  4 ++++
 arch/arm64/kernel/cpufeature.c              | 10 ++++++++++
 2 files changed, 14 insertions(+)

diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
index 014aa1c215a1..57c778446936 100644
--- a/Documentation/arch/arm64/silicon-errata.rst
+++ b/Documentation/arch/arm64/silicon-errata.rst
@@ -242,10 +242,14 @@ stable kernels.
 +----------------+-----------------+-----------------+-----------------------------+
 | ARM            | Neoverse-V3AE   | #4193784        | ARM64_ERRATUM_4118414       |
 +----------------+-----------------+-----------------+-----------------------------+
+| ARM            | C1-Premium      | #3683289        | N/A                         |
++----------------+-----------------+-----------------+-----------------------------+
 | ARM            | C1-Premium      | #4193780        | ARM64_ERRATUM_4118414       |
 +----------------+-----------------+-----------------+-----------------------------+
 | ARM            | C1-Pro          | #4193714        | ARM64_ERRATUM_4193714       |
 +----------------+-----------------+-----------------+-----------------------------+
+| ARM            | C1-Ultra        | #3683289        | N/A                         |
++----------------+-----------------+-----------------+-----------------------------+
 | ARM            | C1-Ultra        | #4193780        | ARM64_ERRATUM_4118414       |
 +----------------+-----------------+-----------------+-----------------------------+
 | ARM            | MMU-500         | #562869,        | ARM_SMMU_MMU_500_CPRE_ERRATA|
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 9a22df0c5120..98d2cfc2dc90 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -2152,6 +2152,16 @@ bool cpu_supports_bbml2_noabort(void)
 		MIDR_ALL_VERSIONS(MIDR_NVIDIA_OLYMPUS),
 		MIDR_ALL_VERSIONS(MIDR_AMPERE1),
 		MIDR_ALL_VERSIONS(MIDR_AMPERE1A),
+		MIDR_ALL_VERSIONS(MIDR_CORTEX_A520AE),
+		MIDR_ALL_VERSIONS(MIDR_CORTEX_A715),
+		MIDR_ALL_VERSIONS(MIDR_CORTEX_A720AE),
+		MIDR_ALL_VERSIONS(MIDR_CORTEX_A725),
+		MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N3),
+		MIDR_ALL_VERSIONS(MIDR_C1_NANO),
+		MIDR_ALL_VERSIONS(MIDR_C1_PRO),
+		/* Erratum 3683289 fixed in r1p1 */
+		MIDR_RANGE(MIDR_C1_ULTRA, 1, 1, 0xf, 0xf),
+		MIDR_RANGE(MIDR_C1_PREMIUM, 1, 1, 0xf, 0xf),
 		{}
 	};
 
-- 
2.43.0

Re: [PATCH v4 3/6] arm64: cpufeature: Extend bbml2_noabort support list

[Anshuman Khandual]

On 23/07/26 10:10 AM, Linu Cherian wrote:
> Add below cpus to the midr list, which supports
> BBML2_NOABORT.
> 
> Cortex A520(AE)
> Cortex A715
> Cortex A720(AE)
> Cortex A725
> Neoverse N3
> C1-Nano
> C1-Pro
> C1-Ultra
> C1-Premium
> 
> C1-Ultra and C1-Premium both suffer from erratum 3683289,
> where Break-Before-Make must be followed to avoid a livelock.
> For both CPUs, the erratum is fixed from r1p1.
> Hence we do not enable BBML2_NOABORT for CPU revisions <= r1p0.
> 
> The relevant SDENs are:
> * C1-Ultra: https://developer.arm.com/documentation/111077/9-00/
> * C1-Premium: https://developer.arm.com/documentation/111078/9-00/
> 
> Reviewed-by: Gavin Shan <gshan@redhat.com>
> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> Signed-off-by: Linu Cherian <linu.cherian@arm.com>
> ---
>  Documentation/arch/arm64/silicon-errata.rst |  4 ++++
>  arch/arm64/kernel/cpufeature.c              | 10 ++++++++++
>  2 files changed, 14 insertions(+)
> 
> diff --git a/Documentation/arch/arm64/silicon-errata.rst b/Documentation/arch/arm64/silicon-errata.rst
> index 014aa1c215a1..57c778446936 100644
> --- a/Documentation/arch/arm64/silicon-errata.rst
> +++ b/Documentation/arch/arm64/silicon-errata.rst
> @@ -242,10 +242,14 @@ stable kernels.
>  +----------------+-----------------+-----------------+-----------------------------+
>  | ARM            | Neoverse-V3AE   | #4193784        | ARM64_ERRATUM_4118414       |
>  +----------------+-----------------+-----------------+-----------------------------+
> +| ARM            | C1-Premium      | #3683289        | N/A                         |
> ++----------------+-----------------+-----------------+-----------------------------+
>  | ARM            | C1-Premium      | #4193780        | ARM64_ERRATUM_4118414       |
>  +----------------+-----------------+-----------------+-----------------------------+
>  | ARM            | C1-Pro          | #4193714        | ARM64_ERRATUM_4193714       |
>  +----------------+-----------------+-----------------+-----------------------------+
> +| ARM            | C1-Ultra        | #3683289        | N/A                         |
> ++----------------+-----------------+-----------------+-----------------------------+
>  | ARM            | C1-Ultra        | #4193780        | ARM64_ERRATUM_4118414       |
>  +----------------+-----------------+-----------------+-----------------------------+
>  | ARM            | MMU-500         | #562869,        | ARM_SMMU_MMU_500_CPRE_ERRATA|
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 9a22df0c5120..98d2cfc2dc90 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -2152,6 +2152,16 @@ bool cpu_supports_bbml2_noabort(void)
>  		MIDR_ALL_VERSIONS(MIDR_NVIDIA_OLYMPUS),
>  		MIDR_ALL_VERSIONS(MIDR_AMPERE1),
>  		MIDR_ALL_VERSIONS(MIDR_AMPERE1A),
> +		MIDR_ALL_VERSIONS(MIDR_CORTEX_A520AE),
> +		MIDR_ALL_VERSIONS(MIDR_CORTEX_A715),
> +		MIDR_ALL_VERSIONS(MIDR_CORTEX_A720AE),
> +		MIDR_ALL_VERSIONS(MIDR_CORTEX_A725),
> +		MIDR_ALL_VERSIONS(MIDR_NEOVERSE_N3),
> +		MIDR_ALL_VERSIONS(MIDR_C1_NANO),
> +		MIDR_ALL_VERSIONS(MIDR_C1_PRO),
> +		/* Erratum 3683289 fixed in r1p1 */
> +		MIDR_RANGE(MIDR_C1_ULTRA, 1, 1, 0xf, 0xf),
> +		MIDR_RANGE(MIDR_C1_PREMIUM, 1, 1, 0xf, 0xf),

This in line with what Mark had suggested earlier.
>  		{}
>  	};
>  

[PATCH v4 4/6] arm64: sysreg: Add BBM_3

[Linu Cherian]

Add BBM_3 definition for ID_AA64MMFR2_EL1 register.

Reviewed-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Linu Cherian <linu.cherian@arm.com>
---
 arch/arm64/tools/sysreg | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
index 7cb61aca3797..e070ada06196 100644
--- a/arch/arm64/tools/sysreg
+++ b/arch/arm64/tools/sysreg
@@ -2259,6 +2259,7 @@ UnsignedEnum	55:52	BBM
 	0b0000	0
 	0b0001	1
 	0b0010	2
+	0b0011	3
 EndEnum
 UnsignedEnum	51:48	TTL
 	0b0000	NI
-- 
2.43.0

[PATCH v4 5/6] arm64: cpufeature: Rename BBML2_NOABORT as BBML3

[Linu Cherian]

- As bbml2_noabort is functionally equivalent to bbml3,
  rename cpu/system_supports_bbml2_noabort to
  cpu/system_supports_bbml3.
  The ARM64 capability name is also renamed accordingly.

- As BBML2_NOABORT or the equivalent BBML3 is the
  kernel requirement for setting up linear map with
  block/contpte mappings and not BBML2, replace all
  bbml2 references with bbml3.

FEAT_BBML3, is introduced as part of 2025 Architecture Extensions.
https://developer.arm.com/documentation/109697/2026_03/2025-Architecture-Extensions

No functional changes are introduced with this patch.

Reviewed-by: Gavin Shan <gshan@redhat.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Linu Cherian <linu.cherian@arm.com>
---
 arch/arm64/include/asm/cpufeature.h |  6 ++--
 arch/arm64/kernel/cpufeature.c      | 30 +++++-----------
 arch/arm64/mm/contpte.c             | 21 +++++------
 arch/arm64/mm/mmu.c                 | 54 ++++++++++++++---------------
 arch/arm64/mm/proc.S                |  4 +--
 arch/arm64/tools/cpucaps            |  2 +-
 6 files changed, 50 insertions(+), 67 deletions(-)

diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index a57870fa96db..d90040fb9de6 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -878,11 +878,11 @@ static inline bool system_supports_pmuv3(void)
 	return cpus_have_final_cap(ARM64_HAS_PMUV3);
 }
 
-bool cpu_supports_bbml2_noabort(void);
+bool cpu_supports_bbml3(void);
 
-static inline bool system_supports_bbml2_noabort(void)
+static inline bool system_supports_bbml3(void)
 {
-	return alternative_has_cap_unlikely(ARM64_HAS_BBML2_NOABORT);
+	return alternative_has_cap_unlikely(ARM64_HAS_BBML3);
 }
 
 int do_emulate_mrs(struct pt_regs *regs, u32 sys_reg, u32 rt);
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 98d2cfc2dc90..896bafdb00b1 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -2131,21 +2131,10 @@ static bool hvhe_possible(const struct arm64_cpu_capabilities *entry,
 	return arm64_test_sw_feature_override(ARM64_SW_FEATURE_OVERRIDE_HVHE);
 }
 
-bool cpu_supports_bbml2_noabort(void)
+bool cpu_supports_bbml3(void)
 {
-	/*
-	 * We want to allow usage of BBML2 in as wide a range of kernel contexts
-	 * as possible. This list is therefore an allow-list of known-good
-	 * implementations that both support BBML2 and additionally, fulfill the
-	 * extra constraint of never generating TLB conflict aborts when using
-	 * the relaxed BBML2 semantics (such aborts make use of BBML2 in certain
-	 * kernel contexts difficult to prove safe against recursive aborts).
-	 *
-	 * Note that implementations can only be considered "known-good" if their
-	 * implementors attest to the fact that the implementation never raises
-	 * TLB conflict aborts for BBML2 mapping granularity changes.
-	 */
-	static const struct midr_range supports_bbml2_noabort_list[] = {
+	/* CPUs that support BBML3 but dont advertise through ID_AA64MMFR2_EL1 */
+	static const struct midr_range supports_bbml3_list[] = {
 		MIDR_REV_RANGE(MIDR_CORTEX_X4, 0, 3, 0xf),
 		MIDR_REV_RANGE(MIDR_NEOVERSE_V3, 0, 2, 0xf),
 		MIDR_REV_RANGE(MIDR_NEOVERSE_V3AE, 0, 2, 0xf),
@@ -2165,8 +2154,7 @@ bool cpu_supports_bbml2_noabort(void)
 		{}
 	};
 
-	/* Does our cpu guarantee to never raise TLB conflict aborts? */
-	if (!is_midr_in_range_list(supports_bbml2_noabort_list))
+	if (!is_midr_in_range_list(supports_bbml3_list))
 		return false;
 
 	/*
@@ -2177,9 +2165,9 @@ bool cpu_supports_bbml2_noabort(void)
 	return true;
 }
 
-static bool has_bbml2_noabort(const struct arm64_cpu_capabilities *caps, int scope)
+static bool has_bbml3(const struct arm64_cpu_capabilities *caps, int scope)
 {
-	return cpu_supports_bbml2_noabort();
+	return cpu_supports_bbml3();
 }
 
 static void cpu_enable_pan(const struct arm64_cpu_capabilities *__unused)
@@ -3072,10 +3060,10 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		ARM64_CPUID_FIELDS(ID_AA64MMFR2_EL1, EVT, IMP)
 	},
 	{
-		.desc = "BBM Level 2 without TLB conflict abort",
-		.capability = ARM64_HAS_BBML2_NOABORT,
+		.desc = "BBM Level 3",
+		.capability = ARM64_HAS_BBML3,
 		.type = ARM64_CPUCAP_EARLY_LOCAL_CPU_FEATURE,
-		.matches = has_bbml2_noabort,
+		.matches = has_bbml3,
 	},
 	{
 		.desc = "52-bit Virtual Addressing for KVM (LPA2)",
diff --git a/arch/arm64/mm/contpte.c b/arch/arm64/mm/contpte.c
index 2de12656b4d8..0acab179fc1a 100644
--- a/arch/arm64/mm/contpte.c
+++ b/arch/arm64/mm/contpte.c
@@ -89,7 +89,7 @@ static void contpte_convert(struct mm_struct *mm, unsigned long addr,
 	}
 
 	/*
-	 * On eliding the __tlb_flush_range() under BBML2+noabort:
+	 * On eliding the __tlb_flush_range() under BBML3:
 	 *
 	 * NOTE: Instead of using N=16 as the contiguous block length, we use
 	 *       N=4 for clarity.
@@ -135,7 +135,7 @@ static void contpte_convert(struct mm_struct *mm, unsigned long addr,
 	 * contiguous TLB entry, which is a micro-optimisation opportunity,
 	 * but does not affect correctness.
 	 *
-	 * In the BBML2 case, the change is avoiding the intermediate tlbi+dsb.
+	 * In the BBML3 case, the change is avoiding the intermediate tlbi+dsb.
 	 * This means a few things, but notably other PEs will still "see" any
 	 * stale cached TLB entries. This could lead to a "contiguous bit
 	 * misprogramming" issue until the final tlbi+dsb of the changed page,
@@ -158,21 +158,16 @@ static void contpte_convert(struct mm_struct *mm, unsigned long addr,
 	 *  are present, and a write is made to this address, do we fault or
 	 *  is the write permitted (via amalgamation)?
 	 *
-	 * The relevant Arm ARM DDI 0487L.a requirements are RNGLXZ and RJQQTC,
-	 * and together state that when BBML1 or BBML2 are implemented, either
-	 * a TLB conflict abort is raised (which we expressly forbid), or will
-	 * "produce an OA, access permissions, and memory attributes that are
-	 * consistent with any of the programmed translation table values".
-	 *
-	 * That is to say, will either raise a TLB conflict, or produce one of
-	 * the cached TLB entries, but never amalgamate.
+	 * With BBML3 implemented, no TLB conflict abort is raised and the OA,
+	 * access permissions and memory attributes produced is one of the cached
+	 * TLB entries, but never amalgamate.
 	 *
 	 * Thus, as the page tables are only considered "consistent" after
 	 * the final tlbi+dsb (which evicts both the single stale (RW,n) TLB
 	 * entry as well as the new contiguous (RO,c) TLB entry), omitting the
 	 * initial tlbi+dsb is correct.
 	 *
-	 * It is also important to note that at the end of the BBML2 folding
+	 * It is also important to note that at the end of the BBML3 folding
 	 * case, we are still left with potentially all N TLB entries still
 	 * cached (the N-1 non-contiguous ptes, and the single contiguous
 	 * block). However, over time, natural TLB pressure will cause the
@@ -214,7 +209,7 @@ static void contpte_convert(struct mm_struct *mm, unsigned long addr,
 	 *
 	 *                  |____| <--- tlbi + dsb
 	 *
-	 * For BBML2, we again remove the intermediate tlbi+dsb. Here, there
+	 * For BBML3, we again remove the intermediate tlbi+dsb. Here, there
 	 * are no issues, as the final tlbi+dsb covering the changed page is
 	 * guaranteed to remove the original large contiguous (RW,c) TLB entry,
 	 * as well as the intermediate (RW,n) TLB entry; the next access will
@@ -224,7 +219,7 @@ static void contpte_convert(struct mm_struct *mm, unsigned long addr,
 	 * regardless.
 	 */
 
-	if (!system_supports_bbml2_noabort())
+	if (!system_supports_bbml3())
 		__flush_tlb_range(&vma, start_addr, addr, PAGE_SIZE, 3,
 				  TLBF_NOWALKCACHE);
 
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index a25d8beacc83..fad71d6bff40 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -779,18 +779,18 @@ static int split_kernel_leaf_mapping_locked(unsigned long addr)
 
 static inline bool force_pte_mapping(void)
 {
-	const bool bbml2 = system_capabilities_finalized() ?
-		system_supports_bbml2_noabort() : cpu_supports_bbml2_noabort();
+	const bool bbml3 = system_capabilities_finalized() ?
+		system_supports_bbml3() : cpu_supports_bbml3();
 
 	if (debug_pagealloc_enabled())
 		return true;
-	if (bbml2)
+	if (bbml3)
 		return false;
 	return rodata_full || arm64_kfence_can_set_direct_map() || is_realm_world();
 }
 
 static DEFINE_MUTEX(pgtable_split_lock);
-static bool linear_map_requires_bbml2;
+static bool linear_map_requires_bbml3;
 
 int split_kernel_leaf_mapping(unsigned long start, unsigned long end)
 {
@@ -803,15 +803,15 @@ int split_kernel_leaf_mapping(unsigned long start, unsigned long end)
 	 * always pte-mapped), we must not go any further because taking the
 	 * mutex below may sleep. Do not call force_pte_mapping() here because
 	 * it could return a confusing result if called from a secondary cpu
-	 * prior to finalizing caps. Instead, linear_map_requires_bbml2 gives us
+	 * prior to finalizing caps. Instead, linear_map_requires_bbml3 gives us
 	 * what we need.
 	 */
-	if (!linear_map_requires_bbml2 || is_kfence_address((void *)start))
+	if (!linear_map_requires_bbml3 || is_kfence_address((void *)start))
 		return 0;
 
-	if (!system_supports_bbml2_noabort()) {
+	if (!system_supports_bbml3()) {
 		/*
-		 * !BBML2_NOABORT systems should not be trying to change
+		 * BBML3 systems should not be trying to change
 		 * permissions on anything that is not pte-mapped in the first
 		 * place. Just return early and let the permission change code
 		 * raise a warning if not already pte-mapped.
@@ -828,8 +828,8 @@ int split_kernel_leaf_mapping(unsigned long start, unsigned long end)
 
 		/*
 		 * Boot-time: Started secondary cpus but don't know if they
-		 * support BBML2_NOABORT yet. Can't allow splitting in this
-		 * window in case they don't.
+		 * support BBML3 yet. Can't allow splitting in this window
+		 * in case they don't.
 		 */
 		if (WARN_ON(num_online_cpus() > 1))
 			return -EBUSY;
@@ -934,11 +934,11 @@ static int range_split_to_ptes(unsigned long start, unsigned long end, gfp_t gfp
 	return ret;
 }
 
-u32 idmap_kpti_bbml2_flag;
+u32 idmap_kpti_bbml3_flag;
 
-static void __init init_idmap_kpti_bbml2_flag(void)
+static void __init init_idmap_kpti_bbml3_flag(void)
 {
-	WRITE_ONCE(idmap_kpti_bbml2_flag, 1);
+	WRITE_ONCE(idmap_kpti_bbml3_flag, 1);
 	/* Must be visible to other CPUs before stop_machine() is called. */
 	smp_mb();
 }
@@ -947,7 +947,7 @@ static int __init linear_map_split_to_ptes(void *__unused)
 {
 	/*
 	 * Repainting the linear map must be done by CPU0 (the boot CPU) because
-	 * that's the only CPU that we know supports BBML2. The other CPUs will
+	 * that's the only CPU that we know supports BBML3. The other CPUs will
 	 * be held in a waiting area with the idmap active.
 	 */
 	if (!smp_processor_id()) {
@@ -960,7 +960,7 @@ static int __init linear_map_split_to_ptes(void *__unused)
 		/*
 		 * Wait for all secondary CPUs to be put into the waiting area.
 		 */
-		smp_cond_load_acquire(&idmap_kpti_bbml2_flag, VAL == num_online_cpus());
+		smp_cond_load_acquire(&idmap_kpti_bbml3_flag, VAL == num_online_cpus());
 
 		/*
 		 * Walk all of the linear map [lstart, lend), except the kernel
@@ -979,7 +979,7 @@ static int __init linear_map_split_to_ptes(void *__unused)
 		 * Relies on dsb in flush_tlb_kernel_range() to avoid reordering
 		 * before any page table split operations.
 		 */
-		WRITE_ONCE(idmap_kpti_bbml2_flag, 0);
+		WRITE_ONCE(idmap_kpti_bbml3_flag, 0);
 	} else {
 		typedef void (wait_split_fn)(void);
 		extern wait_split_fn wait_linear_map_split_to_ptes;
@@ -988,7 +988,7 @@ static int __init linear_map_split_to_ptes(void *__unused)
 		wait_fn = (void *)__pa_symbol(wait_linear_map_split_to_ptes);
 
 		/*
-		 * At least one secondary CPU doesn't support BBML2 so cannot
+		 * At least one secondary CPU doesn't support BBML3 so cannot
 		 * tolerate the size of the live mappings changing. So have the
 		 * secondary CPUs wait for the boot CPU to make the changes
 		 * with the idmap active and init_mm inactive.
@@ -1003,8 +1003,8 @@ static int __init linear_map_split_to_ptes(void *__unused)
 
 void __init linear_map_maybe_split_to_ptes(void)
 {
-	if (linear_map_requires_bbml2 && !system_supports_bbml2_noabort()) {
-		init_idmap_kpti_bbml2_flag();
+	if (linear_map_requires_bbml3 && !system_supports_bbml3()) {
+		init_idmap_kpti_bbml3_flag();
 		stop_machine(linear_map_split_to_ptes, NULL, cpu_online_mask);
 	}
 }
@@ -1127,7 +1127,7 @@ bool arch_kfence_init_pool(void)
 	mutex_unlock(&pgtable_split_lock);
 
 	/*
-	 * Since the system supports bbml2_noabort, tlb invalidation is not
+	 * Since the system supports bbml3, tlb invalidation is not
 	 * required here; the pgtable mappings have been split to pte but larger
 	 * entries may safely linger in the TLB.
 	 */
@@ -1166,7 +1166,7 @@ static void __init map_mem(void)
 
 	arm64_kfence_map_pool();
 
-	linear_map_requires_bbml2 = !force_pte_mapping() && can_set_direct_map();
+	linear_map_requires_bbml3 = !force_pte_mapping() && can_set_direct_map();
 
 	if (force_pte_mapping())
 		flags |= NO_BLOCK_MAPPINGS | NO_CONT_MAPPINGS;
@@ -1333,7 +1333,7 @@ void __init kpti_install_ng_mappings(void)
 	if (arm64_use_ng_mappings)
 		return;
 
-	init_idmap_kpti_bbml2_flag();
+	init_idmap_kpti_bbml3_flag();
 	stop_machine(__kpti_install_ng_mappings, NULL, cpu_online_mask);
 }
 
@@ -1394,7 +1394,7 @@ void __pi_map_range(phys_addr_t *pte, u64 start, u64 end, phys_addr_t pa,
 		    u64 va_offset);
 
 static u8 idmap_ptes[IDMAP_LEVELS - 1][PAGE_SIZE] __aligned(PAGE_SIZE) __ro_after_init,
-	  kpti_bbml2_ptes[IDMAP_LEVELS - 1][PAGE_SIZE] __aligned(PAGE_SIZE) __ro_after_init;
+	  kpti_bbml3_ptes[IDMAP_LEVELS - 1][PAGE_SIZE] __aligned(PAGE_SIZE) __ro_after_init;
 
 static void __init create_idmap(void)
 {
@@ -1406,17 +1406,17 @@ static void __init create_idmap(void)
 		       IDMAP_ROOT_LEVEL, (pte_t *)idmap_pg_dir, false,
 		       __phys_to_virt(ptep) - ptep);
 
-	if (linear_map_requires_bbml2 ||
+	if (linear_map_requires_bbml3 ||
 	    (IS_ENABLED(CONFIG_UNMAP_KERNEL_AT_EL0) && !arm64_use_ng_mappings)) {
-		phys_addr_t pa = __pa_symbol(&idmap_kpti_bbml2_flag);
+		phys_addr_t pa = __pa_symbol(&idmap_kpti_bbml3_flag);
 
 		/*
 		 * The KPTI G-to-nG conversion code needs a read-write mapping
 		 * of its synchronization flag in the ID map. This is also used
 		 * when splitting the linear map to ptes if a secondary CPU
-		 * doesn't support bbml2.
+		 * doesn't support bbml3.
 		 */
-		ptep = __pa_symbol(kpti_bbml2_ptes);
+		ptep = __pa_symbol(kpti_bbml3_ptes);
 		__pi_map_range(&ptep, pa, pa + sizeof(u32), pa, PAGE_KERNEL,
 			       IDMAP_ROOT_LEVEL, (pte_t *)idmap_pg_dir, false,
 			       __phys_to_virt(ptep) - ptep);
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 22866b49be37..f4e4e71a0ea8 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -287,7 +287,7 @@ SYM_TYPED_FUNC_START(idmap_kpti_install_ng_mappings)
 
 	mov	x5, x3				// preserve temp_pte arg
 	mrs	swapper_ttb, ttbr1_el1
-	adr_l	flag_ptr, idmap_kpti_bbml2_flag
+	adr_l	flag_ptr, idmap_kpti_bbml3_flag
 
 	cbnz	cpu, __idmap_kpti_secondary
 
@@ -445,7 +445,7 @@ SYM_TYPED_FUNC_START(wait_linear_map_split_to_ptes)
 	flag_ptr	.req	x4
 
 	mrs     swapper_ttb, ttbr1_el1
-	adr_l   flag_ptr, idmap_kpti_bbml2_flag
+	adr_l   flag_ptr, idmap_kpti_bbml3_flag
 	__idmap_cpu_set_reserved_ttbr1 x16, x17
 
 scondary_cpu_wait:
diff --git a/arch/arm64/tools/cpucaps b/arch/arm64/tools/cpucaps
index 9b85a84f6fd4..c05371365d14 100644
--- a/arch/arm64/tools/cpucaps
+++ b/arch/arm64/tools/cpucaps
@@ -14,6 +14,7 @@ HAS_ADDRESS_AUTH_ARCH_QARMA5
 HAS_ADDRESS_AUTH_IMP_DEF
 HAS_AMU_EXTN
 HAS_ARMv8_4_TTL
+HAS_BBML3
 HAS_CACHE_DIC
 HAS_CACHE_IDC
 HAS_CNP
@@ -51,7 +52,6 @@ HAS_LS64_V
 HAS_LSUI
 HAS_MOPS
 HAS_NESTED_VIRT
-HAS_BBML2_NOABORT
 HAS_PAN
 HAS_PMUV3
 HAS_S1PIE
-- 
2.43.0

Re: [PATCH v4 5/6] arm64: cpufeature: Rename BBML2_NOABORT as BBML3

[Will Deacon]

On Thu, Jul 23, 2026 at 10:10:32AM +0530, Linu Cherian wrote:
> - As bbml2_noabort is functionally equivalent to bbml3,
>   rename cpu/system_supports_bbml2_noabort to
>   cpu/system_supports_bbml3.
>   The ARM64 capability name is also renamed accordingly.
> 
> - As BBML2_NOABORT or the equivalent BBML3 is the
>   kernel requirement for setting up linear map with
>   block/contpte mappings and not BBML2, replace all
>   bbml2 references with bbml3.
> 
> FEAT_BBML3, is introduced as part of 2025 Architecture Extensions.
> https://developer.arm.com/documentation/109697/2026_03/2025-Architecture-Extensions
> 
> No functional changes are introduced with this patch.
> 
> Reviewed-by: Gavin Shan <gshan@redhat.com>
> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> Signed-off-by: Linu Cherian <linu.cherian@arm.com>
> ---
>  arch/arm64/include/asm/cpufeature.h |  6 ++--
>  arch/arm64/kernel/cpufeature.c      | 30 +++++-----------
>  arch/arm64/mm/contpte.c             | 21 +++++------
>  arch/arm64/mm/mmu.c                 | 54 ++++++++++++++---------------
>  arch/arm64/mm/proc.S                |  4 +--
>  arch/arm64/tools/cpucaps            |  2 +-
>  6 files changed, 50 insertions(+), 67 deletions(-)

This breaks the build because you haven't updated the caller in the SMMUv3
SVA code.

I'll push a fix on top...

Will

Re: [PATCH v4 5/6] arm64: cpufeature: Rename BBML2_NOABORT as BBML3

[Linu Cherian]

On Thu, Aug 06, 2026 at 06:11:32PM +0100, Will Deacon wrote:
> On Thu, Jul 23, 2026 at 10:10:32AM +0530, Linu Cherian wrote:
> > - As bbml2_noabort is functionally equivalent to bbml3,
> >   rename cpu/system_supports_bbml2_noabort to
> >   cpu/system_supports_bbml3.
> >   The ARM64 capability name is also renamed accordingly.
> > 
> > - As BBML2_NOABORT or the equivalent BBML3 is the
> >   kernel requirement for setting up linear map with
> >   block/contpte mappings and not BBML2, replace all
> >   bbml2 references with bbml3.
> > 
> > FEAT_BBML3, is introduced as part of 2025 Architecture Extensions.
> > https://developer.arm.com/documentation/109697/2026_03/2025-Architecture-Extensions
> > 
> > No functional changes are introduced with this patch.
> > 
> > Reviewed-by: Gavin Shan <gshan@redhat.com>
> > Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> > Signed-off-by: Linu Cherian <linu.cherian@arm.com>
> > ---
> >  arch/arm64/include/asm/cpufeature.h |  6 ++--
> >  arch/arm64/kernel/cpufeature.c      | 30 +++++-----------
> >  arch/arm64/mm/contpte.c             | 21 +++++------
> >  arch/arm64/mm/mmu.c                 | 54 ++++++++++++++---------------
> >  arch/arm64/mm/proc.S                |  4 +--
> >  arch/arm64/tools/cpucaps            |  2 +-
> >  6 files changed, 50 insertions(+), 67 deletions(-)
> 
> This breaks the build because you haven't updated the caller in the SMMUv3
> SVA code.
> 
> I'll push a fix on top...

Yeah, i missed that. Thanks for pointing out and the fix.

> 
> Will

[PATCH v4 6/6] arm64: cpufeature: Detect BBML3 based on ID_AA64MMFR2_EL1.BBM

[Linu Cherian]

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 <gshan@redhat.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Signed-off-by: Linu Cherian <linu.cherian@arm.com>
---
 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;
+
 	/* CPUs that support BBML3 but dont advertise through ID_AA64MMFR2_EL1 */
 	static const struct midr_range supports_bbml3_list[] = {
 		MIDR_REV_RANGE(MIDR_CORTEX_X4, 0, 3, 0xf),
@@ -2154,15 +2160,10 @@ bool cpu_supports_bbml3(void)
 		{}
 	};
 
-	if (!is_midr_in_range_list(supports_bbml3_list))
-		return false;
-
-	/*
-	 * We currently ignore the ID_AA64MMFR2_EL1 register, and only care
-	 * about whether the MIDR check passes.
-	 */
+	if (is_midr_in_range_list(supports_bbml3_list))
+		return true;
 
-	return true;
+	return false;
 }
 
 static bool has_bbml3(const struct arm64_cpu_capabilities *caps, int scope)
-- 
2.43.0

Re: [PATCH v4 6/6] arm64: cpufeature: Detect BBML3 based on ID_AA64MMFR2_EL1.BBM

[Will Deacon]

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 <gshan@redhat.com>
> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> Signed-off-by: Linu Cherian <linu.cherian@arm.com>
> ---
>  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).

Will

Re: [PATCH v4 6/6] arm64: cpufeature: Detect BBML3 based on ID_AA64MMFR2_EL1.BBM

[Linu Cherian]

Hi Will,

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 <gshan@redhat.com>
> > Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> > Signed-off-by: Linu Cherian <linu.cherian@arm.com>
> > ---
> >  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 ?

Thanks,
Linu Cherian.

Re: [PATCH v4 6/6] arm64: cpufeature: Detect BBML3 based on ID_AA64MMFR2_EL1.BBM

[Anshuman Khandual]

On 03/08/26 9:22 AM, Linu Cherian wrote:
> Hi Will,
> 
> 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 <gshan@redhat.com>
>>> Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
>>> Signed-off-by: Linu Cherian <linu.cherian@arm.com>
>>> ---
>>>  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 ?
Right - that would be useful here while also providing some
context why has_cpuid_feature() could not have been used.

Re: [PATCH v4 6/6] arm64: cpufeature: Detect BBML3 based on ID_AA64MMFR2_EL1.BBM

[Will Deacon]

On Mon, Aug 03, 2026 at 09:22:02AM +0530, Linu Cherian wrote:
> Hi Will,
> 
> 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 <gshan@redhat.com>
> > > Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> > > Signed-off-by: Linu Cherian <linu.cherian@arm.com>
> > > ---
> > >  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?

Will

Re: [PATCH v4 6/6] arm64: cpufeature: Detect BBML3 based on ID_AA64MMFR2_EL1.BBM

[Linu Cherian]

Hi,

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:
> > Hi Will,
> > 
> > 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 <gshan@redhat.com>
> > > > Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> > > > Signed-off-by: Linu Cherian <linu.cherian@arm.com>
> > > > ---
> > > >  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. 


  
> 
> Will

Re: [PATCH v4 6/6] arm64: cpufeature: Detect BBML3 based on ID_AA64MMFR2_EL1.BBM

[Will Deacon]

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 <gshan@redhat.com>
> > > > > Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
> > > > > Signed-off-by: Linu Cherian <linu.cherian@arm.com>
> > > > > ---
> > > > >  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

Re: [PATCH v4 0/6] Add BBML3 cpu feature

[Will Deacon]

On Thu, 23 Jul 2026 10:10:27 +0530, Linu Cherian wrote:
> - Patches 1, 2 and 3 adds more cpus to the bbml2_noabort
>   support list. bbml2_noabort would eventually gets renamed
>   to bbml3 in a subsequent patch as they are functionally
>   equivalent.
> - Patches 4, 5 & 6 introduces BBML3 cpu feature
> 
> Changelog from v3:
> * In order to cover future C1-Ultra and C1-Premium cpus starting
> from r1p1, replaced MIDR_REV_RANGE with MIDR_RANGE in patch 3
> 
> [...]

Applied to arm64 (for-next/cpufeature), thanks!

[1/6] arm64: cputype: Add Cortex-A520AE definitions
      https://git.kernel.org/arm64/c/482145e0327f
[2/6] arm64: cputype: Add C1-Nano definitions
      https://git.kernel.org/arm64/c/357230cb5276
[3/6] arm64: cpufeature: Extend bbml2_noabort support list
      https://git.kernel.org/arm64/c/a7ac60414475
[4/6] arm64: sysreg: Add BBM_3
      https://git.kernel.org/arm64/c/e4fa24624308
[5/6] arm64: cpufeature: Rename BBML2_NOABORT as BBML3
      https://git.kernel.org/arm64/c/94104e3cfa80
[6/6] arm64: cpufeature: Detect BBML3 based on ID_AA64MMFR2_EL1.BBM
      https://git.kernel.org/arm64/c/879aca5119cd

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev