From: Nicolin Chen <nicolinc@nvidia.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: Michael Shavit <mshavit@google.com>, <iommu@lists.linux.dev>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <will@kernel.org>,
<robin.murphy@arm.com>, <jean-philippe@linaro.org>
Subject: Re: [PATCH v4 6/8] iommu/arm-smmu-v3: Move CD table to arm_smmu_master
Date: Fri, 4 Aug 2023 16:11:41 -0700 [thread overview]
Message-ID: <ZM2FrQcD8QzP6XM0@Asurada-Nvidia> (raw)
In-Reply-To: <ZM1/vx0bgNZXYcY6@nvidia.com>
On Fri, Aug 04, 2023 at 07:46:23PM -0300, Jason Gunthorpe wrote:
> On Fri, Aug 04, 2023 at 03:25:43PM -0700, Nicolin Chen wrote:
> > > @@ -2436,22 +2419,14 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
> > > if (!smmu_domain->smmu) {
> > > smmu_domain->smmu = smmu;
> > > ret = arm_smmu_domain_finalise(domain, master);
> > > - if (ret) {
> > > + if (ret)
> > > smmu_domain->smmu = NULL;
> > > - goto out_unlock;
> > > - }
> > > - } else if (smmu_domain->smmu != smmu) {
> > > + } else if (smmu_domain->smmu != smmu)
> > > ret = -EINVAL;
> > > - goto out_unlock;
> > > - } else if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1 &&
> > > - master->ssid_bits != smmu_domain->cd_table.max_cds_bits) {
> > > - ret = -EINVAL;
> > > - goto out_unlock;
> > > - } else if (smmu_domain->stage == ARM_SMMU_DOMAIN_S1 &&
> > > - smmu_domain->cd_table.stall_enabled != master->stall_enabled) {
> > > - ret = -EINVAL;
> > > - goto out_unlock;
> > > - }
> >
> > ... then we remove this stall_enabled sanity also.
> >
> > This means a shared domain (holding a shared CD) being inserted
> > to two CD tables from two masters would have two different CDTE
> > configurations at the stall bit.
>
> I looked through the spec for a while and I thought this was fine..
>
> Stall is basically a master specific behavior on how to operate page
> faulting. It makes sense that it follows the master and the IOPTEs in
> the domain can be used with both the faulting and non-faulting page
> faulting path.
>
> I would expect the page faulting path to figure out what to (if there
> is anything special to do) do based on the master that triggered the
> fault, not based on the domain that received it.
Yea, I went through the spec too yet didn't find anything that
could block us. And there is no SW dependency on the STALL bit
of the CDTE: actually it has an inverse relationship with the
S1STALLD bit in the STE, so following the STE/cd_table/master
makes sense. So long as a master has its own cd_table holding
its own CDTE for a shared domain, HW CD caching should be fine
as well.
With that being said, I think mentioning this behavior change
in the commit log wouldn't hurt. Someday people might want to
check this out in case something breaks.
Thanks
Nic
next prev parent reply other threads:[~2023-08-04 23:11 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-02 16:32 [PATCH v4 0/8] Refactor the SMMU's CD table ownership Michael Shavit
2023-08-02 16:32 ` [PATCH v4 1/8] iommu/arm-smmu-v3: Move ctx_desc out of s1_cfg Michael Shavit
2023-08-04 19:19 ` Nicolin Chen
2023-08-02 16:32 ` [PATCH v4 2/8] iommu/arm-smmu-v3: Replace s1_cfg with cdtab_cfg Michael Shavit
2023-08-04 19:25 ` Nicolin Chen
2023-08-02 16:32 ` [PATCH v4 3/8] iommu/arm-smmu-v3: Encapsulate ctx_desc_cfg init in alloc_cd_tables Michael Shavit
2023-08-04 19:27 ` Nicolin Chen
2023-08-02 16:32 ` [PATCH v4 4/8] iommu/arm-smmu-v3: move stall_enabled to the cd table Michael Shavit
2023-08-04 23:32 ` Nicolin Chen
2023-08-07 12:21 ` Michael Shavit
2023-08-02 16:32 ` [PATCH v4 5/8] iommu/arm-smmu-v3: Refactor write_ctx_desc Michael Shavit
2023-08-04 20:22 ` Nicolin Chen
2023-08-07 12:26 ` Michael Shavit
2023-08-02 16:32 ` [PATCH v4 6/8] iommu/arm-smmu-v3: Move CD table to arm_smmu_master Michael Shavit
2023-08-03 17:56 ` Michael Shavit
2023-08-03 18:47 ` Jason Gunthorpe
2023-08-07 12:19 ` Michael Shavit
2023-08-07 22:41 ` Jason Gunthorpe
2023-08-04 22:25 ` Nicolin Chen
2023-08-04 22:46 ` Jason Gunthorpe
2023-08-04 23:11 ` Nicolin Chen [this message]
2023-08-02 16:32 ` [PATCH v4 7/8] iommu/arm-smmu-v3: Skip cd sync if CD table isn't active Michael Shavit
2023-08-04 19:59 ` Nicolin Chen
2023-08-07 15:02 ` Michael Shavit
2023-08-02 16:32 ` [PATCH v4 8/8] iommu/arm-smmu-v3: Rename cdcfg to cd_table Michael Shavit
2023-08-04 19:31 ` Nicolin Chen
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=ZM2FrQcD8QzP6XM0@Asurada-Nvidia \
--to=nicolinc@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=jean-philippe@linaro.org \
--cc=jgg@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mshavit@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox