On Fri, Jan 16, 2026 at 10:41:20AM -0400, Jason Gunthorpe wrote:

On Thu, Jan 15, 2026 at 09:13:00PM -0800, Nicolin Chen wrote:

quoted

On Fri, Jan 02, 2026 at 11:57:15AM -0400, Jason Gunthorpe wrote:

quoted

On Tue, Dec 30, 2025 at 10:52:53AM -0800, Nicolin Chen wrote:

quoted

Hi Jason,

On Fri, Dec 19, 2025 at 01:05:51PM -0400, Jason Gunthorpe wrote:

quoted

+static int arm_smmu_get_tag(struct arm_smmu_domain *smmu_domain,
+			    struct arm_smmu_master *master,
+			    struct arm_vsmmu *vsmmu,
+			    struct arm_smmu_iotlb_tag *tag, bool no_alloc)

[...]

quoted

+	case ARM_SMMU_DOMAIN_S2:
+		if (smmu_domain->nest_parent) {
+			/* FIXME we can support attaching a nest_parent without
+			 * a vsmmu, but to do that we need to fix
+			 * arm_smmu_get_id_from_invs() to never return the vmid
+			 * of a vsmmu. Probably by making a
+			 * INV_TYPE_S2_VMID_VSMMU */
+			id = vsmmu->vmid;
+			return 0;
+		}

Would you mind elaborating why arm_smmu_get_id_from_invs() can't
return vsmmu->vmid to share with a naked S2 STE?

A "naked" S2 domain doesn't have a pointer to the vsmmu, so it is
impossible to get vsmmu->vmid.

An S2 parent domain should be per VM. And a vSMMU on top of an S2
should be per SMMU. So, it could have stored a list of vSMMUs and
device attaching to a naked S2 could match its master->smmu with
vSMMU->smmu in the list?

That would cause lifecycle problems if the vSMMU is destroyed
while the nake S2 is still attached and trying to use the vSMMU's
VMID.

Well, if vSMMU code does the same get-build-merge in vsmmu_init()
and build-unref in vsmmu_destroy(), VMID is basically managed by
the invalidation array. Yes, a naked S2 attachment would still use
the shared VMID, but I think that's fine for a nesting parent?

That being said, the implementation isn't going to be as clean as
your approach.

Nicolin