linux-kernel - Re: [PATCH v1 2/9] iommu/arm-smmu-v3: Add alloc_id/free_id functions to arm_smmu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20260117011108.GE1134360@nvidia.com>
Date: Fri, 16 Jan 2026 21:11:08 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Nicolin Chen <nicolinc@...dia.com>
Cc: will@...nel.org, robin.murphy@....com, joro@...tes.org, jpb@...nel.org,
	praan@...gle.com, miko.lenczewski@....com,
	linux-arm-kernel@...ts.infradead.org, iommu@...ts.linux.dev,
	linux-kernel@...r.kernel.org, patches@...ts.linux.dev
Subject: Re: [PATCH v1 2/9] iommu/arm-smmu-v3: Add alloc_id/free_id functions
 to arm_smmu_invs

On Fri, Jan 16, 2026 at 10:27:25AM -0800, Nicolin Chen wrote:
> On Fri, Jan 16, 2026 at 01:11:58PM -0400, Jason Gunthorpe wrote:
> > On Fri, Jan 16, 2026 at 08:58:02AM -0800, Nicolin Chen wrote:
> > > 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:
> > > > > On Fri, Jan 02, 2026 at 11:57:15AM -0400, Jason Gunthorpe wrote:
> > > > > > On Tue, Dec 30, 2025 at 10:52:53AM -0800, Nicolin Chen wrote:
> > > > > > > Hi Jason,
> > > > > > > 
> > > > > > > On Fri, Dec 19, 2025 at 01:05:51PM -0400, Jason Gunthorpe wrote:
> > > > > > > > +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)
> > > > > > > [...]
> > > > > > > > +	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?
> > 
> > The VMID has to be managed by the vsmmu itself, it would be a big
> > confusing mess any other way. There are multiple invalidation lists,
> > so you can't rely on that to refcount things.
> 
> Hmm, in which case will we have multiple invalidation lists? And,
> why can't we rely on the refcount? (for learning purpose here)

Well, you could have multiple S2s floating around the system, you'd
need to have some way to figure out which S2 is which nesting parent
for which viommu.

> My view is that VM has one big beautiful invalidation list on the
> S2 parent domain, which manages all the VMIDs. So, basically VMIDs
> could be still tied to the S2 parent domain on attachments. And a
> VMID must be one per SMMU instance, whether initially allocated by
> a naked or a nested attachment. A second user would just increase
> the refcount.

I guess that could work but it makes it much more complicated IMHO.

It would be simpler if there is only ever one refcount on the VMID for
the vsmmu in the S2's list and that goes away when the VSMMU is
destroyed.

Jason