Re: [PATCH v3 1/2] arm64: Add override for MMFR1.HAFDBS

On 28/07/2026 11:03 am, Will Deacon wrote:

On Mon, Jul 27, 2026 at 01:03:28PM +0100, Robin Murphy wrote:

quoted

In general it might be nice to have the ability to disable hardware
access/dirty bit management for debugging or performance comparison
purposes without having to rebuild the kernel. However once FEAT_HAFT
comes into the picture we also start to have a real functional concern
where the decision to use HAFT based on the boot CPUs can prevent SVA
or late-onlining if SMMUs/CPUs are later found to lack HAFT support.

To that end, add the appropriate MMFR1 override, with an easy "nohaft"
alias for the significant case, partly since the feature/field naming
isn't the most obvious, but also so it could potentially be redirected
in future if someone wanted to attempt a higher-level means of turning
off just HAFT usage independently from FEAT_HDBSS.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---

v3: No change.

  Documentation/admin-guide/kernel-parameters.txt | 3 +++
  arch/arm64/kernel/pi/idreg-override.c           | 2 ++
  2 files changed, 5 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index b5493a7f8f22..7f23e5b8dc44 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt

@@ -565,6 +565,9 @@ Kernel parameters
  	arm64.nogcs	[ARM64] Unconditionally disable Guarded Control Stack
  			support
  
+	arm64.nohaft	[ARM64] Unconditionally disable Hardware managed Access
+			Flag for Table descriptors support
+
  	arm64.nomops	[ARM64] Unconditionally disable Memory Copy and Memory
  			Set instructions support
  

diff --git a/arch/arm64/kernel/pi/idreg-override.c b/arch/arm64/kernel/pi/idreg-override.c
index bc57b290e5e7..0e051fec5afe 100644
--- a/arch/arm64/kernel/pi/idreg-override.c
+++ b/arch/arm64/kernel/pi/idreg-override.c

@@ -64,6 +64,7 @@ static const struct ftr_set_desc mmfr1 __prel64_initconst = {
  	.override	= &id_aa64mmfr1_override,
  	.fields		= {
  		FIELD("vh", ID_AA64MMFR1_EL1_VH_SHIFT, mmfr1_vh_filter),
+		FIELD("hafdbs", ID_AA64MMFR1_EL1_HAFDBS_SHIFT, NULL),
  		{}
  	},
  };

@@ -246,6 +247,7 @@ static const struct {
  	{ "arm64.nomte",		"id_aa64pfr1.mte=0" },
  	{ "nokaslr",			"arm64_sw.nokaslr=1" },
  	{ "rodata=off",			"arm64_sw.rodataoff=1" },
+	{ "arm64.nohaft",		"id_aa64mmfr1.hafdbs=2" },

What happens if I pass this option on a CPU that doesn't implement
HTTU at all? Will that then end up *enabling* HA and HD?

Nope - that's what I checked, hence my comment on v2 being grateful to 
Marc for making the framework so idiot-proof ;)

It combines the override value with the detected CPU features in the 
usual way, and since HAFDBS is a LOWER_SAFE feature it all works out. 
Booting a Juno with "id_aa64mmfr1.hafdbs=17" has no effect other than 
printing a message that it ignored the override.

Cheers,
Robin.