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

[Robin Murphy <robin.murphy@arm.com>]

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.