Re: [PATCH] iommu/arm-smmu-v3-sva: Relax ASID requirements

[Jason Gunthorpe <jgg@ziepe.ca>]

On Tue, Sep 08, 2026 at 08:38:58AM +0000, Mostafa Saleh wrote:
> On Mon, Sep 07, 2026 at 03:45:13PM -0300, Jason Gunthorpe wrote:
> > On Mon, Sep 07, 2026 at 03:49:28PM +0000, Mostafa Saleh wrote:
> > > arm_smmu_sva_supported() have some residual checks for ASID from the
> > > original commit d744f9e6c222 ("iommu/arm-smmu-v3: Check for SVA features")
> > > 
> > > As DVM was used for TLB invalidation and the ASID of the domain was shared
> > > with the CPU process.
> > > 
> > > However, the commit
> > > d38c28dbefee ("iommu/arm-smmu-v3: Put the SVA mmu notifier in the smmu_domain")
> > > removed that support.
> > > 
> > > So matching the SMMU ASID space to the CPU is unnecessary and can be
> > > relaxed.
> > > 
> > > Remove the CPU ASID related code, and update the print for the SMMUv3.
> > 
> > It is OK, but maybe this could also be but under an if
> > ARM_SMMU_FEAT_BTM?  That is never enabled and is a placeholder to for
> > eventual BTM support.
> 
> Yes, otherwise SMMUs with BTM would regress in the future.
> But I’d assume non-BTM SMMUs will still be supported; falling back
> to SW invalidation?

Yeah, there is no idea to make BTM mandatory, just some people who
built BTM into their HW would like to use it because it maybe performs
better.

So the thought was if the HW supports it then Linux would turn it on
automatically for SVA.

I think we can land "vBTM" support upstream which does not require
solving the ASID problem since in a VM there would be no S2 at all.

The main issue was renumbering the ASIDs of already active
domains. Prior to the invs list this could not be done correctly
without races. Now that we can invalidate the same domain multiple
times in the invs list it can be done race free.

But, I don't have any BTM HW.

Jason