All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peng Fan <peng.fan@oss.nxp.com>
To: Jason Gunthorpe <jgg@ziepe.ca>,
	Robin Murphy <robin.murphy@arm.com>,
	Nicolin Chen <nicolinc@nvidia.com>
Cc: Robin Murphy <robin.murphy@arm.com>,
	Nicolin Chen <nicolinc@nvidia.com>, Will Deacon <will@kernel.org>,
	"Joerg Roedel (AMD)" <joro@8bytes.org>,
	Jean-Philippe Brucker <jpb@kernel.org>,
	Thierry Reding <thierry.reding@kernel.org>,
	Krishna Reddy <vdumpa@nvidia.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
	linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org,
	Peng Fan <peng.fan@nxp.com>
Subject: Re: [PATCH RFC v6 5/5] iommu/arm-smmu-v3: Wire up shared-SID STE ordering and feature gating
Date: Tue, 13 Oct 2026 22:46:28 +0800	[thread overview]
Message-ID: <as5ERENDfgC6FB0b@shlinux89> (raw)
In-Reply-To: <20261013124400.GI14213@ziepe.ca>

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

  reply	other threads:[~2026-10-13 14:42 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-11 11:31 [PATCH RFC v6 0/5] iommu/arm-smmu-v3: Support shared Stream IDs Peng Fan (OSS)
2026-10-11 11:31 ` [PATCH RFC v6 1/5] iommu/arm-smmu-v3: Allocate streams individually Peng Fan (OSS)
2026-10-11 11:31 ` [PATCH RFC v6 2/5] iommu/arm-smmu-v3: Delay stream allocation to inside the mutex Peng Fan (OSS)
2026-10-12 20:36   ` Nicolin Chen
2026-10-11 11:31 ` [PATCH RFC v6 3/5] iommu/arm-smmu-v3: Support shared SIDs in insert/remove_master Peng Fan (OSS)
2026-10-12 20:48   ` Nicolin Chen
2026-10-11 11:31 ` [PATCH RFC v6 4/5] iommu/arm-smmu-v3: Group aliasing devices into the same IOMMU group Peng Fan (OSS)
2026-10-12 12:24   ` Peng Fan
2026-10-12 13:05     ` Robin Murphy
2026-10-11 11:31 ` [PATCH RFC v6 5/5] iommu/arm-smmu-v3: Wire up shared-SID STE ordering and feature gating Peng Fan (OSS)
2026-10-12 13:23   ` Peng Fan
2026-10-12 23:54     ` Nicolin Chen
2026-10-13 11:22       ` Robin Murphy
2026-10-13 12:44         ` Jason Gunthorpe
2026-10-13 14:46           ` Peng Fan [this message]
2026-10-13 15:14             ` Jason Gunthorpe
2026-10-13 18:26               ` Nicolin Chen
2026-10-13 16:23           ` Robin Murphy

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=as5ERENDfgC6FB0b@shlinux89 \
    --to=peng.fan@oss.nxp.com \
    --cc=iommu@lists.linux.dev \
    --cc=jgg@ziepe.ca \
    --cc=jonathanh@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=jpb@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=nicolinc@nvidia.com \
    --cc=peng.fan@nxp.com \
    --cc=robin.murphy@arm.com \
    --cc=thierry.reding@kernel.org \
    --cc=vdumpa@nvidia.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.