[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 at vger.kernel.org>
> > > Fixes: 62df5870ebf7 ("arm64: Enable ARCH_HAS_NONLEAF_PMD_YOUNG")
> > > Signed-off-by: Robin Murphy <robin.murphy at 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