Re: [PATCH RFC v6 5/5] iommu/arm-smmu-v3: Wire up shared-SID STE ordering and feature gating

[Nicolin Chen <nicolinc@nvidia.com>]

On Tue, Oct 13, 2026 at 05:23:21PM +0100, Robin Murphy wrote:
> On 13/10/2026 1:44 pm, Jason Gunthorpe wrote:
> > On Tue, Oct 13, 2026 at 12:22:06PM +0100, Robin Murphy wrote:
> > > If we're not going to support PASID for shared streams (which I suggest we
> > > don't...) than we shouldn't strictly need to worry about CD tables anyway.
> > > So rather than having to special-case CD table sharing for shared streams,
> > > perhaps it might make sense to generalise back to a "default" per-domain CD
> > > for non-PASID use, which can then get switched for the private per-stream
> > > cd_table if and when a device does enable PASID?
> > 
> > If we have stared STEs then the group becomes the per-STE data
> > structure not the master.. We don't have any way right now to do that,
> > but it would make some sense for the group to store the shared CD
> 
> That would be precisely the aforementioned special case that I'd hope to
> avoid. My point is that the CD represents the domain context, so we really
> shouldn't have to have multiple copies of that per-device _or_ per-group,
> _unless_ it is attached via a PASID, since in that case it does need to be
> copied into a per-device CD table (since the per-domain CD table was indeed
> the wrong move in hindsight).
> 
> So what I'm saying is that if we're going to make anything share CDs, then
> ideally we should just make all non-PASID devices always directly share the
> domain's own CD, then if we just enforce that any devices sharing StreamIDs
> must be non-PASID devices, it should all work out, we save some memory in
> the normal case, and never have to be concerned with rewriting any STE with
> a different S1ContextPtr for the _same_ domain except when enabling or
> disabling PASID for the (single) device owning that STE.

FWIW, master->ats_always_on would be a special case here: it is
non-PASID but needs s1cdmax to be non zero.

But yea, that sounds like a good approach, though requires a big
refactor.

Thanks
Nicolin