[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

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

[Robin Murphy]

On 2026-07-03 8:24 pm, Jason Gunthorpe wrote:
> 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..

HA and HD are effectively just a performance feature, since the software 
fault handler only ends up setting the PTE bits such that the outcome is 
the same either way, it's just hideously inefficient to have to take the 
whole round-trip through the SMMU event queue. HAFT is different because 
it's already a strict superset of HA so there is no software-handlable 
fault; table AFs will *only* be set by agents with HAFT enabled, and 
thus a mismatch leads to actual loss of correctness if a HAFT-aware 
pmd_young() assumes that AF=0 in a table entry means there must be no 
leaf PTEs with AF=1 below it.
>> 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.

Indeed if anyone does want to use SVA on such mismatched hardware and 
are happy to use a custom kernel with CONFIG_ARM64_HAFT disabled then 
they can and will continue to be able to do so. However I don't feel 
it's right to make general distros do that if they want to ship SVA 
support, as then it means future systems that don't use SVA, or do have 
system-wide HAFT, lose out on an additional performance feature 
unnecessarily (I guess if HiSilicon added it to their CPU they might 
have added it to their SMMU as well and just overlooked enabling it?)

Furthermore, as I alluded to, with the idreg-override stuff it should be 
easy enough to add the further option of suppressing HAFT from the 
command line if anyone wants that.

Thanks,
Robin

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

[Jason Gunthorpe]

On Mon, Jul 06, 2026 at 03:13:01PM +0100, Robin Murphy wrote:

> Indeed if anyone does want to use SVA on such mismatched hardware and are
> happy to use a custom kernel with CONFIG_ARM64_HAFT disabled then they can
> and will continue to be able to do so.

It seems like we have a chip that is impacted by this. I'm being told
that the necessary ARM IP is not available in time to properly match
SMMU and CPU for its particular application.d

The chip is embedded so those work arounds are possibly OK - but I
think this issue keeps coming up and ARM should have a better overall
solution for CPU/SMMU mismatch in the ecosystem since it seems like
this is going to keep happening..

Even if Linux could automatically limit the CPU features to the SMMU
it would be a big help.

Jason

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

[Robin Murphy]

On 09/07/2026 5:04 pm, Jason Gunthorpe wrote:
> On Mon, Jul 06, 2026 at 03:13:01PM +0100, Robin Murphy wrote:
> 
>> Indeed if anyone does want to use SVA on such mismatched hardware and are
>> happy to use a custom kernel with CONFIG_ARM64_HAFT disabled then they can
>> and will continue to be able to do so.
> 
> It seems like we have a chip that is impacted by this. I'm being told
> that the necessary ARM IP is not available in time to properly match
> SMMU and CPU for its particular application.d
> 
> The chip is embedded so those work arounds are possibly OK - but I
> think this issue keeps coming up and ARM should have a better overall
> solution for CPU/SMMU mismatch in the ecosystem since it seems like
> this is going to keep happening..

To be fair, even if new VMSA features were added to the SMMU 
architecture in lockstep with the CPU architecture (which historically 
they haven't been since the SMMU version often needs additional 
consideration - oh, the fun we had with HDBSS...), and the SMMU products 
were developed and released in sync with CPU products (which again they 
have not been, for more than just architecture reasons), then at the end 
of the day from the Linux perspective we'd still have to deal with 
licensees having the freedom to play mix-and-match, so I don't see 
there's much that Arm could really do.

The CPU architecture does now provide FEAT_IDTE3, which platform 
firmware can use to hide visibility of features from an OS/hypervisor, 
so if you did ask, I suspect you'd get the answer that beyond that it's 
up to the OS to decide what it wants to do with what it's given.

> Even if Linux could automatically limit the CPU features to the SMMU
> it would be a big help.

Feel free to propose patches, but given that SMMU details may not be 
known until after userspace is up (since the driver can be a module), 
unless features can safely be toggled on and off entirely dynamically, 
for many cases I don't see that we could ever do much more than letting 
the user pick their preferred policy at boot time via config or command 
line.

Thanks,
Robin.

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

[Will Deacon]

On Wed, Jul 01, 2026 at 06:45:17PM +0100, Robin Murphy wrote:
> 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(+)

This looks ok to *me*, but Sashiko raises two interesting points:

https://sashiko.dev/#/patchset/878cd6bcbbe2d5677d2f63da13294c148268552c.1782927917.git.robin.murphy@arm.com

1. This may break hitless updates when transitioning to a faulting entry.
2. IORT has HTTU overrides for HA/HD. Does it (will it?) have anything
   for HAFT? At the moment, it looks like you'll trigger a warning
   message.

Given Jason's comments, it's probably worth sending the idreg override
patch as well...

Will

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

[Robin Murphy]

On 22/07/2026 2:24 pm, Will Deacon wrote:
> On Wed, Jul 01, 2026 at 06:45:17PM +0100, Robin Murphy wrote:
>> 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(+)
> 
> This looks ok to *me*, but Sashiko raises two interesting points:
> 
> https://sashiko.dev/#/patchset/878cd6bcbbe2d5677d2f63da13294c148268552c.1782927917.git.robin.murphy@arm.com
> 
> 1. This may break hitless updates when transitioning to a faulting entry.

What does that even mean? We might block traffic in the process of 
_explicitly blocking traffic_!? Whoop-de-do, surely?

But either way, HAFT has bog all to do with EPD0, and it must be cleared 
if HA is cleared, otherwise the CD becomes illegal.

> 2. IORT has HTTU overrides for HA/HD. Does it (will it?) have anything
>     for HAFT? At the moment, it looks like you'll trigger a warning
>     message.

Oh, seems I did miss that fiddly fw_features line, so I guess it has 
half a point that the warning can wonky if both IDR0 and IORT do 
(correctly) report HAFT. Pretty sure we're already a bit broken if IORT 
ever did try to override HTTU _upwards_, though.

> Given Jason's comments, it's probably worth sending the idreg override
> patch as well...

Fair enough, I'm blessed with a moment of calm just now so I should be 
able to find time to have a crack at that tomorrow...

Cheers,
Robin.

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

[Will Deacon]

On Wed, Jul 22, 2026 at 05:56:25PM +0100, Robin Murphy wrote:
> On 22/07/2026 2:24 pm, Will Deacon wrote:
> > On Wed, Jul 01, 2026 at 06:45:17PM +0100, Robin Murphy wrote:
> > > 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(+)
> > 
> > This looks ok to *me*, but Sashiko raises two interesting points:
> > 
> > https://sashiko.dev/#/patchset/878cd6bcbbe2d5677d2f63da13294c148268552c.1782927917.git.robin.murphy@arm.com
> > 
> > 1. This may break hitless updates when transitioning to a faulting entry.
> 
> What does that even mean?

Hey, I'm not daft enough to spend time on all the Sashiko reviews going
on! That's why I pointed it out without trying to comprehend it :)

> We might block traffic in the process of _explicitly blocking traffic_!?
> Whoop-de-do, surely?

Hmm. I have very vague memories that there were some virtualisation (?)
cases where Jason and Nicolin cared about the type of event that would
be generated by concurrent DMA (e.g. bad CD vs translation fault) but
maybe I'm misremembering.

> But either way, HAFT has bog all to do with EPD0, and it must be cleared if
> HA is cleared, otherwise the CD becomes illegal.

That appears to be the case.

> > 2. IORT has HTTU overrides for HA/HD. Does it (will it?) have anything
> >     for HAFT? At the moment, it looks like you'll trigger a warning
> >     message.
> 
> Oh, seems I did miss that fiddly fw_features line, so I guess it has half a
> point that the warning can wonky if both IDR0 and IORT do (correctly) report
> HAFT. Pretty sure we're already a bit broken if IORT ever did try to
> override HTTU _upwards_, though.

Ah, I hadn't spotted that you'd already added the IORT part, so yes, this
just looks like the mask needs extending.

> > Given Jason's comments, it's probably worth sending the idreg override
> > patch as well...
> 
> Fair enough, I'm blessed with a moment of calm just now so I should be able
> to find time to have a crack at that tomorrow...

Brill, thank you.

Will

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

[Jason Gunthorpe]

On Wed, Jul 22, 2026 at 11:20:48PM +0100, Will Deacon wrote:

> > We might block traffic in the process of _explicitly blocking traffic_!?
> > Whoop-de-do, surely?
> 
> Hmm. I have very vague memories that there were some virtualisation (?)
> cases where Jason and Nicolin cared about the type of event that would
> be generated by concurrent DMA (e.g. bad CD vs translation fault) but
> maybe I'm misremembering.

Yeah, it is actually important for that special SVA mm drop/release
case. We need to write a CD that blocks walking but always generates
translation fault.

I'm away from my computer right now, but if sashiko is saying that the
SVA flow that uses EPD generates a racy bad CD then that is a bug that
needs to be fixed. Possibly by ignoring HAFT in the used calculation
for the EPD cases.

We should also try to have a kunit to cover that specific mm drop flow
in the SVA code.

Jason

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

[Robin Murphy]

On 24/07/2026 4:25 pm, Jason Gunthorpe wrote:
> On Wed, Jul 22, 2026 at 11:20:48PM +0100, Will Deacon wrote:
> 
>>> We might block traffic in the process of _explicitly blocking traffic_!?
>>> Whoop-de-do, surely?
>>
>> Hmm. I have very vague memories that there were some virtualisation (?)
>> cases where Jason and Nicolin cared about the type of event that would
>> be generated by concurrent DMA (e.g. bad CD vs translation fault) but
>> maybe I'm misremembering.
> 
> Yeah, it is actually important for that special SVA mm drop/release
> case. We need to write a CD that blocks walking but always generates
> translation fault.
> 
> I'm away from my computer right now, but if sashiko is saying that the
> SVA flow that uses EPD generates a racy bad CD then that is a bug that
> needs to be fixed. Possibly by ignoring HAFT in the used calculation
> for the EPD cases.

Again, HAFT has nothing whatsoever to do with EPD0. Guess what happens 
if we were to ignore it as nonsensically suggested? Oh look, C_BAD_CD 
again, since a valid CD with HA=0 and HAFT=1 is architecturally illegal.

I also wouldn't consider this a "regression", as I'm not aware of any 
SMMU actually implementing HAFT yet - this is more just about ensuring 
architectural correctness is in place ready for the future. There should 
be plenty of time to figure out if and how you could still do what you 
want to do on future hardware, but if the SMMUv3 architecture itself 
breaks your idea of how the SMMUv3 driver should work, then forgive me 
for not having all that much sympathy, since my responsibility is 
primarily to support the architecture and correct usage thereof.

Thanks,
Robin.