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

Peng Fan peng.fan at oss.nxp.com
Tue Oct 13 07:46:28 PDT 2026


Hi Nicolin, Robin, Jason

On Tue, Oct 13, 2026 at 09:44:00AM -0300, 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

Thanks for the detailed feedback, reply you all here.

For the CD table question: since shared-SID masters are in the same
group and always use the same domain, the CD content is identical.
With skip_shared_ste(), only stream->master's STE (and thus its
cd_table) is active in hardware.  The other masters' cd_tables are
allocated but never referenced by the STE.

I see two options:

A) Keep skip_shared_ste() and add arm_smmu_cd_owner() to redirect
   all cd_table operations to stream->master. This is a minimal
   change that works for our use case (platform devices, no PASID,
   no domain switching).

B) Drop skip_shared_ste() entirely and share the CD table at the
   group or domain level. This is cleaner but a larger change.

I'm leaning towards (A) for now to keep the series focused on the
simple shared-SID case.  Would that be acceptable, or do you prefer
we go with (B) from the start?

Thanks,
Peng
>
>Jason
>
>



More information about the linux-arm-kernel mailing list