All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peng Fan <peng.fan@oss.nxp.com>
To: Nicolin Chen <nicolinc@nvidia.com>
Cc: will@kernel.org, robin.murphy@arm.com, joro@8bytes.org,
	jpb@kernel.org, jgg@ziepe.ca,
	linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
	linux-kernel@vger.kernel.org, peng.fan@nxp.com
Subject: Re: [PATCH RFC v2 2/4] iommu/arm-smmu-v3: Support shared SIDs in insert/remove_master
Date: Tue, 22 Sep 2026 22:13:56 +0800	[thread overview]
Message-ID: <arKNJH2YWQT9KL7x@shlinux89> (raw)
In-Reply-To: <arG6hmng3NddGEHm@nvidia.com>

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 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
>
>

  reply	other threads:[~2026-09-22 14:09 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-21 11:34 [PATCH RFC v2 0/4] iommu/arm-smmu-v3: Support shared Stream IDs Peng Fan (OSS)
2026-09-21 11:35 ` [PATCH RFC v2 1/4] iommu/arm-smmu-v3: Convert streams from RB tree to XArray Peng Fan (OSS)
2026-09-21 19:24   ` Nicolin Chen
2026-09-22 14:04     ` Peng Fan
2026-09-22 16:56       ` Nicolin Chen
2026-09-21 12:38 ` [PATCH RFC v2 2/4] iommu/arm-smmu-v3: Support shared SIDs in insert/remove_master Peng Fan (OSS)
2026-09-21 23:15   ` Nicolin Chen
2026-09-22 14:13     ` Peng Fan [this message]
2026-09-22 15:52       ` Robin Murphy
2026-09-22 17:47         ` Nicolin Chen
2026-09-21 12:40 ` [PATCH RFC v2 3/4] iommu/arm-smmu-v3: Group aliasing devices into the same IOMMU group Peng Fan (OSS)
2026-09-21 12:41 ` [PATCH RFC v2 4/4] iommu/arm-smmu-v3: Wire up shared-SID STE ordering and feature gating Peng Fan (OSS)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=arKNJH2YWQT9KL7x@shlinux89 \
    --to=peng.fan@oss.nxp.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=joro@8bytes.org \
    --cc=jpb@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicolinc@nvidia.com \
    --cc=peng.fan@nxp.com \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.