[PATCH] iommu/arm-smmu-v3: Add HAFT support for SVA

[PATCH] iommu/arm-smmu-v3: Add HAFT support for SVA

[Robin Murphy]

Since table access flags cannot be software-managed, if process
pagetables are using HAFT then SVA must require the SMMU to support and
enable it too, otherwise page aging is liable to get out of whack.

Cc: <stable@vger.kernel.org>
Fixes: 62df5870ebf7 ("arm64: Enable ARCH_HAS_NONLEAF_PMD_YOUNG")
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 5 +++++
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c     | 6 ++++++
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h     | 3 +++
 3 files changed, 14 insertions(+)

diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
index 1ed8a6f29dc4..ef11e9493f93 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c
@@ -102,6 +102,8 @@ void arm_smmu_make_sva_cd(struct arm_smmu_cd *target,
 			target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HA);
 		if (master->smmu->features & ARM_SMMU_FEAT_HD)
 			target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_HD);
+		if (master->smmu->features & ARM_SMMU_FEAT_HAFT && system_supports_haft())
+			target->data[1] |= cpu_to_le64(CTXDESC_CD_1_HAFT);
 	} else {
 		target->data[0] |= cpu_to_le64(CTXDESC_CD_0_TCR_EPD0);
 
@@ -211,6 +213,9 @@ bool arm_smmu_sva_supported(struct arm_smmu_device *smmu)
 	if (system_supports_bbml2_noabort())
 		feat_mask |= ARM_SMMU_FEAT_BBML2;
 
+	if (system_supports_haft())
+		feat_mask |= ARM_SMMU_FEAT_HAFT;
+
 	if ((smmu->features & feat_mask) != feat_mask)
 		return false;
 
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
index a10affb483a4..7637e9128533 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
@@ -4925,6 +4925,9 @@ static void arm_smmu_get_httu(struct arm_smmu_device *smmu, u32 reg)
 	u32 hw_features = 0;
 
 	switch (FIELD_GET(IDR0_HTTU, reg)) {
+	case IDR0_HTTU_ACCESS_DIRTY_HAFT:
+		hw_features |= ARM_SMMU_FEAT_HAFT;
+		fallthrough;
 	case IDR0_HTTU_ACCESS_DIRTY:
 		hw_features |= ARM_SMMU_FEAT_HD;
 		fallthrough;
@@ -5256,6 +5259,9 @@ static int arm_smmu_device_acpi_probe(struct platform_device *pdev,
 		smmu->features |= ARM_SMMU_FEAT_COHERENCY;
 
 	switch (FIELD_GET(ACPI_IORT_SMMU_V3_HTTU_OVERRIDE, iort_smmu->flags)) {
+	case IDR0_HTTU_ACCESS_DIRTY_HAFT:
+		smmu->features |= ARM_SMMU_FEAT_HAFT;
+		fallthrough;
 	case IDR0_HTTU_ACCESS_DIRTY:
 		smmu->features |= ARM_SMMU_FEAT_HD;
 		fallthrough;
diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
index c909c9a88538..61a7df5afb99 100644
--- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
+++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
@@ -40,6 +40,7 @@ struct arm_vsmmu;
 #define IDR0_HTTU			GENMASK(7, 6)
 #define IDR0_HTTU_ACCESS		1
 #define IDR0_HTTU_ACCESS_DIRTY		2
+#define IDR0_HTTU_ACCESS_DIRTY_HAFT	3
 #define IDR0_COHACC			(1 << 4)
 #define IDR0_TTF			GENMASK(3, 2)
 #define IDR0_TTF_AARCH64		2
@@ -369,6 +370,7 @@ static inline unsigned int arm_smmu_cdtab_l2_idx(unsigned int ssid)
 #define CTXDESC_CD_0_ASET		(1UL << 47)
 #define CTXDESC_CD_0_ASID		GENMASK_ULL(63, 48)
 
+#define CTXDESC_CD_1_HAFT		(1UL << 3)
 #define CTXDESC_CD_1_TTB0_MASK		GENMASK_ULL(51, 4)
 
 /*
@@ -921,6 +923,7 @@ struct arm_smmu_device {
 #define ARM_SMMU_FEAT_HD		(1 << 22)
 #define ARM_SMMU_FEAT_S2FWB		(1 << 23)
 #define ARM_SMMU_FEAT_BBML2		(1 << 24)
+#define ARM_SMMU_FEAT_HAFT		(1 << 25)
 	u32				features;
 
 #define ARM_SMMU_OPT_SKIP_PREFETCH	(1 << 0)
-- 
2.54.0.dirty

Re: [PATCH] iommu/arm-smmu-v3: Add HAFT support for SVA

[Jason Gunthorpe]

On Wed, Jul 01, 2026 at 06:45:17PM +0100, Robin Murphy wrote:

> @@ -211,6 +213,9 @@ bool arm_smmu_sva_supported(struct arm_smmu_device *smmu)
>  	if (system_supports_bbml2_noabort())
>  		feat_mask |= ARM_SMMU_FEAT_BBML2;
>  
> +	if (system_supports_haft())
> +		feat_mask |= ARM_SMMU_FEAT_HAFT;

I fear this is going to make SVA stop working on systems it currently
does work on, so it might be a major regression. 

SMMU HTTU is not a commonly implemented feature.. I think of all the
NVIDIA ARM chips only one supports it. Given that a quick internal
check is raising concerns this will be breaking for us. We need to
check in more detail which cores have HAFT.

Breaking already deployed SVA would be a major functional regression.

I think this should start by just enabling SMMU HAFT when CPU HAFT is
on, when possible. Maybe print a warning on the mismatch instead of
failing.

Since we can't break already deployed SVA a full solution would either
have to somehow turn off CPU HAFT or we ignore the gap in the AF
updates..

Jason

Re: [PATCH] iommu/arm-smmu-v3: Add HAFT support for SVA

[Robin Murphy]

On 03/07/2026 5:49 pm, Jason Gunthorpe wrote:
> On Wed, Jul 01, 2026 at 06:45:17PM +0100, Robin Murphy wrote:
> 
>> @@ -211,6 +213,9 @@ bool arm_smmu_sva_supported(struct arm_smmu_device *smmu)
>>   	if (system_supports_bbml2_noabort())
>>   		feat_mask |= ARM_SMMU_FEAT_BBML2;
>>   
>> +	if (system_supports_haft())
>> +		feat_mask |= ARM_SMMU_FEAT_HAFT;
> 
> I fear this is going to make SVA stop working on systems it currently
> does work on, so it might be a major regression.
> 
> SMMU HTTU is not a commonly implemented feature.. I think of all the
> NVIDIA ARM chips only one supports it. Given that a quick internal
> check is raising concerns this will be breaking for us. We need to
> check in more detail which cores have HAFT.
> 
> Breaking already deployed SVA would be a major functional regression.
> 
> I think this should start by just enabling SMMU HAFT when CPU HAFT is
> on, when possible. Maybe print a warning on the mismatch instead of
> failing.
> 
> Since we can't break already deployed SVA a full solution would either
> have to somehow turn off CPU HAFT or we ignore the gap in the AF
> updates..

TBH I do not know how bad the implications of 
pmd_young()/pmdp_test_and_clear_young() returning a false-negative are, 
but if we aren't considering mismatched CPUs harmless then surely the 
same must apply for SVA. In the POE/GCS cases all that can really be 
broken is users' expectations, if they've opted in to additional 
security features, but also opted in to SVA wherein those features can't 
protect against DMA. Here, though, it's the kernel mm layer itself 
that's impacted, and I'm not confident to say that that isn't more serious.

This came about as a sudden "oh crap" moment when answering an internal 
query about SMMU features, and it seemed prudent to do _something_ for 
the sake of correctness ASAP. Making HAFT depend on !SVA could only 
easily be done at the config level, which seems arguably even more 
over-reaching, and given that CPUs supporting HAFT aren't common yet - 
at least from Arm it seems to be only the big cores of the latest C1 
generation so far - in a pinch this felt like the least-worst option for 
the short term. If someone has time to look into whether it's possible 
to dynamically switch arch_has_hw_nonleaf_pmd_young (and whatever else) 
post-init, then that's an obvious follow-up, but I can say for sure that 
that someone is not me...

Thanks,
Robin.

Re: [PATCH] iommu/arm-smmu-v3: Add HAFT support for SVA

[Jason Gunthorpe]

On Fri, Jul 03, 2026 at 07:57:04PM +0100, Robin Murphy wrote:
> On 03/07/2026 5:49 pm, Jason Gunthorpe wrote:
> > On Wed, Jul 01, 2026 at 06:45:17PM +0100, Robin Murphy wrote:
> > 
> > > @@ -211,6 +213,9 @@ bool arm_smmu_sva_supported(struct arm_smmu_device *smmu)
> > >   	if (system_supports_bbml2_noabort())
> > >   		feat_mask |= ARM_SMMU_FEAT_BBML2;
> > > +	if (system_supports_haft())
> > > +		feat_mask |= ARM_SMMU_FEAT_HAFT;
> > 
> > I fear this is going to make SVA stop working on systems it currently
> > does work on, so it might be a major regression.
> > 
> > SMMU HTTU is not a commonly implemented feature.. I think of all the
> > NVIDIA ARM chips only one supports it. Given that a quick internal
> > check is raising concerns this will be breaking for us. We need to
> > check in more detail which cores have HAFT.
> > 
> > Breaking already deployed SVA would be a major functional regression.
> > 
> > I think this should start by just enabling SMMU HAFT when CPU HAFT is
> > on, when possible. Maybe print a warning on the mismatch instead of
> > failing.
> > 
> > Since we can't break already deployed SVA a full solution would either
> > have to somehow turn off CPU HAFT or we ignore the gap in the AF
> > updates..
> 
> TBH I do not know how bad the implications of
> pmd_young()/pmdp_test_and_clear_young() returning a false-negative are, but
> if we aren't considering mismatched CPUs harmless then surely the same must
> apply for SVA. In the POE/GCS cases all that can really be broken is users'
> expectations, if they've opted in to additional security features, but also
> opted in to SVA wherein those features can't protect against DMA. Here,
> though, it's the kernel mm layer itself that's impacted, and I'm not
> confident to say that that isn't more serious.

This has come up a few times now where the SMMU and CPU
incompatibilities in ARM's IP are causing real headaches.

Let's give it some time and I can say for certain if we have impacted
chips or not. I was able to confirm the server chips are OK, but there
is still some concern about the embedded chips..

I also don't know how harmless it is to ignore the aging. I thought
the PTE was designed to be backwards compatible, but I never looked at
how AF works..

> Making HAFT depend on !SVA could only easily be done at the config
> level, which seems arguably even more over-reaching

Yeah, but if you could build a custom embedded kernel with HAFT
disabled in kconfig maybe that is enough for some people.

Jason