[PATCH v3 1/2] arm64: Add override for MMFR1.HAFDBS
Will Deacon
will at kernel.org
Tue Jul 28 03:03:21 PDT 2026
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 <robin.murphy at 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?
Will
More information about the linux-arm-kernel
mailing list