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:
>> 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 <[email protected]>
>> ---
>>
>> 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.