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

[Peng Fan <peng.fan@oss.nxp.com>]

Hi Nicolin, Robin, Jason

On Tue, Oct 13, 2026 at 12:33:19PM -0700, Nicolin Chen wrote:
>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.

I just post out RFC V7 version with sharing CD table. But I not
have the hardware to test the advanced features (:
only tested i.MX95, Qemu, KUNIT.

Thanks
Peng

>
>Thanks
>Nicolin
>
>