[PATCH RFC v2 2/4] iommu/arm-smmu-v3: Support shared SIDs in insert/remove_master

Robin Murphy robin.murphy at arm.com
Tue Sep 22 08:52:35 PDT 2026


On 22/09/2026 3:13 pm, Peng Fan wrote:
> On Mon, Sep 21, 2026 at 04:15:18PM -0700, Nicolin Chen wrote:
>> On Mon, Sep 21, 2026 at 08:38:46PM +0800, Peng Fan (OSS) wrote:
>>> @@ -976,6 +976,24 @@ struct arm_smmu_device {
>>>   struct arm_smmu_stream {
>>>   	u32				id;
>>>   	struct arm_smmu_master		*master;
>>> +	/*
>>> +	 * ref_count > 1 means multiple masters share this SID.  Protected by
>>> +	 * smmu->streams_mutex.
>>> +	 */
>>> +	unsigned int			ref_count;
>>> +	/*
>>> +	 * When ref_count > 1 the STE has already been written by the first
>>> +	 * master; subsequent masters must skip the write.
>>> +	 */
>>> +	bool				ste_installed;
>>> +	/*
>>> +	 * Links all arm_smmu_stream objects that share the same SID across
>>> +	 * different masters.  The canonical (XArray-stored) entry is the list
>>> +	 * head; non-owning sharers are linked into it.  Used to transfer
>>> +	 * XArray ownership when the current owner is removed.
>>> +	 * Protected by smmu->streams_mutex.
>>> +	 */
>>> +	struct list_head		shared_link;
>>>   };
>>
>> SID-sharing masters still allocate their own streams. Though the
>> SIDs are the same number, they own duplicated streams linked via
>> that "shared_link" list.
>>
>>   master_a->stream[0] --> stream (SID=X) --|
>>                                       shared_link
>>   master_b->stream[0] --> stream (SID=X) --|
>>
>> But maybe they could share the stream structure directly? I.e.
>>
>>   master_a->stream[0] --|
>>                         |--> shared stream (SID=X)
>>   master_b->stream[0] --|
>>
>>
>> The stream structure would still need a list for shared_masters:
>>
>> struct arm_smmu_stream {
>> [...]
>> 	/* Every sharing master, ->master included. Empty unless shared */
>> 	struct list_head shared_masters;
>> };
>>
>> ref_count could be simply !list_empty(&stream->shared_masters).
> 
> Agree.
> 
>>
>>
>> Does i.MX need to support SID-sharing with multi-SD device? If not,
>> the master could have only a simple shared_masters_elm:
> 
> For i.MX, there is no need to support SID sharing for multi-SID device for now.
> Not sure, in future there are cases that needs SID sharing for multi-SID device.

I have a system meeting those conditions :)

Specifically, I have a physical PCIe-to-PCI bridge board with a couple 
of ancient cards plugged into it (such that they each end up with their 
own RID plus the common bridge alias RID) just in case I ever got round 
to looking at this myself...

(And for added fun, one of the cards only supports 31-bit DMA and the 
machine doesn't have any RAM low enough for it to work without the SMMU 
at all)

Cheers,
Robin.

> 
> I could update in V3 following your suggestion.
> 
> Thanks,
> Peng
> 
>>
>> struct arm_smmu_master {
>> [....]
>> 	/* Supports num_streams == 1 only. Empty if SID is not shared */
>> 	struct list_head shared_masters_elm;
>> };
>>
>>> @@ -1024,6 +1042,11 @@ struct arm_smmu_master {
>>>   	bool				ste_ats_enabled : 1;
>>>   	bool				stall_enabled;
>>>   	bool				ats_always_on;
>>> +	/*
>>> +	 * True when at least one of this master's SIDs is shared with another
>>> +	 * master.  SVA, stall and IOPF are disabled for such masters.
>>> +	 */
>>> +	bool				shared_sid;
>>
>> Then, this could be !list_empty(&master->shared_masters_elm).
>>
>> Nicolin
>>
>>




More information about the linux-arm-kernel mailing list