[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