From: Jason Gunthorpe <jgg@nvidia.com>
To: Will Deacon <will@kernel.org>
Cc: Michael Shavit <mshavit@google.com>,
iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, robin.murphy@arm.com,
nicolinc@nvidia.com, jean-philippe@linaro.org
Subject: Re: [PATCH v5 2/9] iommu/arm-smmu-v3: Replace s1_cfg with cdtab_cfg
Date: Wed, 9 Aug 2023 12:08:02 -0300 [thread overview]
Message-ID: <ZNOr0ggoO9kXHJWl@nvidia.com> (raw)
In-Reply-To: <20230809145542.GB4472@willie-the-truck>
On Wed, Aug 09, 2023 at 03:55:43PM +0100, Will Deacon wrote:
> On Wed, Aug 09, 2023 at 10:59:33AM -0300, Jason Gunthorpe wrote:
> > On Wed, Aug 09, 2023 at 02:49:41PM +0100, Will Deacon wrote:
> >
> > > > @@ -1360,10 +1357,14 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_master *master, u32 sid,
> > > > !master->stall_enabled)
> > > > dst[1] |= cpu_to_le64(STRTAB_STE_1_S1STALLD);
> > > >
> > > > - val |= (s1_cfg->cdcfg.cdtab_dma & STRTAB_STE_0_S1CTXPTR_MASK) |
> > > > - FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_S1_TRANS) |
> > > > - FIELD_PREP(STRTAB_STE_0_S1CDMAX, s1_cfg->s1cdmax) |
> > > > - FIELD_PREP(STRTAB_STE_0_S1FMT, s1_cfg->s1fmt);
> > > > + val |= (cd_table->cdtab_dma & STRTAB_STE_0_S1CTXPTR_MASK) |
> > > > + FIELD_PREP(STRTAB_STE_0_CFG, STRTAB_STE_0_CFG_S1_TRANS) |
> > > > + FIELD_PREP(STRTAB_STE_0_S1CDMAX,
> > > > + cd_table->max_cds_bits) |
> > > > + FIELD_PREP(STRTAB_STE_0_S1FMT,
> > > > + cd_table->l1_desc ?
> > > > + STRTAB_STE_0_S1FMT_64K_L2 :
> > > > + STRTAB_STE_0_S1FMT_LINEAR);
> > >
> > > magically know that we're using 64k tables.
> > >
> > > Why is this an improvement to the driver?
> >
> > Put the above in a function
> >
> > arm_smmu_get_cd_ste(struct arm_smmu_ctx_desc_cfg *cdtab, void *ste)
> >
> > And it makes more sense.
>
> Sorry, but I'm not seeing it :/
>
> > We don't need the driver to precompute the "s1_cfg" parameters and
> > store them in a redundant struct along side the ctx_desc_cfg when we
> > can compute those same values on the fly with no cost.
>
> But the computation isn't happening -- the STRTAB_STE_0_S1FMT_64K_L2
> constant is hardcoded here.
So it would be hard coded in arm_smmu_get_cd_ste() because that
reflects the current state of CD table code.
> If we want to use 4k leaf tables in some cases, how would you add
> that? Such a change shouldn't need the low-level strtab creation
> code to change.
You would modify arm_smmu_ctx_desc_cfg to teach it about the different
format. It would gain some (enum?) member that specifies the CD table
layout and geometry. arm_smmu_get_cd_ste() will interpret that member
and generate the correct STE for the specifc cd table.
It is a standard OOP sort of practice that the object self-describes
and has accessors to export its internal definition. In this case the
STE bits are part of/derived from the internal definition of the CD
table.
Jason
next prev parent reply other threads:[~2023-08-09 15:08 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-08 17:11 [PATCH v5 0/9] Refactor the SMMU's CD table ownership Michael Shavit
2023-08-08 17:11 ` [PATCH v5 1/9] iommu/arm-smmu-v3: Move ctx_desc out of s1_cfg Michael Shavit
2023-08-08 17:11 ` [PATCH v5 2/9] iommu/arm-smmu-v3: Replace s1_cfg with cdtab_cfg Michael Shavit
2023-08-09 13:49 ` Will Deacon
2023-08-09 13:59 ` Jason Gunthorpe
2023-08-09 14:55 ` Will Deacon
2023-08-09 15:08 ` Jason Gunthorpe [this message]
2023-08-09 16:22 ` Will Deacon
2023-08-09 16:26 ` Jason Gunthorpe
2023-08-09 16:27 ` Will Deacon
2023-08-10 9:33 ` Michael Shavit
2023-08-10 9:43 ` Will Deacon
2023-08-10 12:04 ` Jason Gunthorpe
2023-08-10 17:15 ` Michael Shavit
2023-08-10 17:32 ` Jason Gunthorpe
2023-08-08 17:11 ` [PATCH v5 3/9] iommu/arm-smmu-v3: Encapsulate ctx_desc_cfg init in alloc_cd_tables Michael Shavit
2023-08-08 17:12 ` [PATCH v5 4/9] iommu/arm-smmu-v3: move stall_enabled to the cd table Michael Shavit
2023-08-08 17:12 ` [PATCH v5 5/9] iommu/arm-smmu-v3: Refactor write_ctx_desc Michael Shavit
2023-08-09 13:50 ` Will Deacon
2023-08-10 9:15 ` Michael Shavit
2023-08-10 14:40 ` Will Deacon
2023-08-10 15:39 ` Jason Gunthorpe
2023-08-15 5:20 ` Michael Shavit
2023-08-15 11:22 ` Jason Gunthorpe
2023-08-15 12:03 ` Michael Shavit
2023-08-15 12:30 ` Jason Gunthorpe
2023-08-15 12:36 ` Michael Shavit
2023-08-15 12:56 ` Jason Gunthorpe
2023-08-15 5:04 ` Michael Shavit
2023-08-15 10:19 ` Will Deacon
2023-08-15 11:40 ` Michael Shavit
2023-08-08 17:12 ` [PATCH v5 6/9] iommu/arm-smmu-v3: Move CD table to arm_smmu_master Michael Shavit
2023-08-09 13:50 ` Will Deacon
2023-08-10 9:23 ` Michael Shavit
2023-08-10 14:38 ` Will Deacon
2023-08-10 9:45 ` Michael Shavit
2023-08-10 14:34 ` Will Deacon
2023-08-10 14:56 ` Jason Gunthorpe
2023-08-15 12:10 ` Michael Shavit
2023-08-08 17:12 ` [PATCH v5 7/9] iommu/arm-smmu-v3: Cleanup arm_smmu_domain_finalise Michael Shavit
2023-08-08 17:12 ` [PATCH v5 8/9] iommu/arm-smmu-v3: Skip cd sync if CD table isn't active Michael Shavit
2023-08-09 13:50 ` Will Deacon
2023-08-10 8:34 ` Michael Shavit
2023-08-10 16:27 ` Will Deacon
2023-08-08 17:12 ` [PATCH v5 9/9] iommu/arm-smmu-v3: Rename cdcfg to cd_table Michael Shavit
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=ZNOr0ggoO9kXHJWl@nvidia.com \
--to=jgg@nvidia.com \
--cc=iommu@lists.linux.dev \
--cc=jean-philippe@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mshavit@google.com \
--cc=nicolinc@nvidia.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