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

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

[Mostafa Saleh]

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.

Signed-off-by: Mostafa Saleh <smostafa@google.com>
---
 drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 16 +---------------
 1 file changed, 1 insertion(+), 15 deletions(-)

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 0a429c64fbf3..a071f9841839 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
@@ -199,7 +199,6 @@ bool arm_smmu_sva_supported(struct arm_smmu_device *smmu)
 {
 	unsigned long reg, fld;
 	unsigned long oas;
-	unsigned long asid_bits;
 	u32 feat_mask = ARM_SMMU_FEAT_COHERENCY;
 
 	if (vabits_actual == 52) {
@@ -232,20 +231,7 @@ bool arm_smmu_sva_supported(struct arm_smmu_device *smmu)
 	if (smmu->oas < oas)
 		return false;
 
-	/* We can support bigger ASIDs than the CPU, but not smaller */
-	fld = cpuid_feature_extract_unsigned_field(reg, ID_AA64MMFR0_EL1_ASIDBITS_SHIFT);
-	asid_bits = fld ? 16 : 8;
-	if (smmu->asid_bits < asid_bits)
-		return false;
-
-	/*
-	 * See max_pinned_asids in arch/arm64/mm/context.c. The following is
-	 * generally the maximum number of bindable processes.
-	 */
-	if (arm64_kernel_unmapped_at_el0())
-		asid_bits--;
-	dev_dbg(smmu->dev, "%d shared contexts\n", (1 << asid_bits) -
-		num_possible_cpus() - 2);
+	dev_dbg(smmu->dev, "Max SMMUv3 SVA contexts: %u\n", 1 << smmu->asid_bits);
 
 	return true;
 }
-- 
2.55.0.979.g7e5102b832-goog

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

[Jason Gunthorpe]

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.

Once we get the last part of the invs code the BTM support can come
back in.

Jasson

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

[Mostafa Saleh]

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?

Thanks,
Mostafa

> 
> Once we get the last part of the invs code the BTM support can come
> back in.
> 
> Jasson

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

[Jason Gunthorpe]

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