From: Mostafa Saleh <smostafa@google.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: iommu@lists.linux.dev, Joerg Roedel <joro@8bytes.org>,
linux-arm-kernel@lists.infradead.org,
Robin Murphy <robin.murphy@arm.com>,
Will Deacon <will@kernel.org>,
Michael Shavit <mshavit@google.com>,
Nicolin Chen <nicolinc@nvidia.com>,
patches@lists.linux.dev, Ryan Roberts <ryan.roberts@arm.com>
Subject: Re: [PATCH 2/7] iommu/arm-smmu-v3: Do not zero the strtab twice
Date: Tue, 4 Jun 2024 15:56:04 +0000 [thread overview]
Message-ID: <Zl85FOpIrQSeto4W@google.com> (raw)
In-Reply-To: <2-v1-1b720dce51d1+4f44-smmuv3_tidy_jgg@nvidia.com>
Hi Jason,
On Mon, Jun 03, 2024 at 07:31:28PM -0300, Jason Gunthorpe wrote:
> dmam_alloc_coherent() already returns zero'd memory so cfg->strtab.l1_desc
> (the list of DMA addresses for the L2 entries) is already zero'd.
>
> arm_smmu_init_l1_strtab() goes through and calls
> arm_smmu_write_strtab_l1_desc() on the newly allocated (and zero'd) struct
> arm_smmu_strtab_l1_desc, which ends up computing 'val = 0' and zeroing it
> again.
>
> Remove arm_smmu_init_l1_strtab() and just call devm_kcalloc() from
> arm_smmu_init_strtab_2lvl to allocate the companion struct.
>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Looking at the code for dmam_alloc_coherent(basically dma_alloc_coherent)
I see that the memory is zeroed for both DMA direct and IOMMU, however
I don’t see that documented (in DMA-API.txt).
Assuming that’s guaranteed to be zeroed (maybe we should update the docs
if I am not missing something)
Reviewed-by: Mostafa Saleh <smostafa@google.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 27 +++++++--------------
> 1 file changed, 9 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index 6b4f1a664288db..d27dd0600bf1df 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -3220,23 +3220,6 @@ static int arm_smmu_init_queues(struct arm_smmu_device *smmu)
> PRIQ_ENT_DWORDS, "priq");
> }
>
> -static int arm_smmu_init_l1_strtab(struct arm_smmu_device *smmu)
> -{
> - unsigned int i;
> - struct arm_smmu_strtab_cfg *cfg = &smmu->strtab_cfg;
> -
> - cfg->l1_desc = devm_kcalloc(smmu->dev, cfg->num_l1_ents,
> - sizeof(*cfg->l1_desc), GFP_KERNEL);
> - if (!cfg->l1_desc)
> - return -ENOMEM;
> -
> - for (i = 0; i < cfg->num_l1_ents; ++i)
> - arm_smmu_write_strtab_l1_desc(
> - &smmu->strtab_cfg.strtab.l1_desc[i], &cfg->l1_desc[i]);
> -
> - return 0;
> -}
> -
> static int arm_smmu_init_strtab_2lvl(struct arm_smmu_device *smmu)
> {
> void *strtab;
> @@ -3272,7 +3255,15 @@ static int arm_smmu_init_strtab_2lvl(struct arm_smmu_device *smmu)
> reg |= FIELD_PREP(STRTAB_BASE_CFG_SPLIT, STRTAB_SPLIT);
> cfg->strtab_base_cfg = reg;
>
> - return arm_smmu_init_l1_strtab(smmu);
> + cfg->l1_desc = devm_kcalloc(smmu->dev, cfg->num_l1_ents,
> + sizeof(*cfg->l1_desc), GFP_KERNEL);
> + if (!cfg->l1_desc) {
> + dev_err(smmu->dev,
> + "failed to allocate l1 stream table (%zu bytes)\n",
> + cfg->num_l1_ents * sizeof(*cfg->l1_desc));
> + return -ENOMEM;
> + }
> + return 0;
> }
>
> static int arm_smmu_init_strtab_linear(struct arm_smmu_device *smmu)
> --
> 2.45.2
>
WARNING: multiple messages have this Message-ID (diff)
From: Mostafa Saleh <smostafa@google.com>
To: Jason Gunthorpe <jgg@nvidia.com>
Cc: iommu@lists.linux.dev, Joerg Roedel <joro@8bytes.org>,
linux-arm-kernel@lists.infradead.org,
Robin Murphy <robin.murphy@arm.com>,
Will Deacon <will@kernel.org>,
Michael Shavit <mshavit@google.com>,
Nicolin Chen <nicolinc@nvidia.com>,
patches@lists.linux.dev, Ryan Roberts <ryan.roberts@arm.com>
Subject: Re: [PATCH 2/7] iommu/arm-smmu-v3: Do not zero the strtab twice
Date: Tue, 4 Jun 2024 15:56:04 +0000 [thread overview]
Message-ID: <Zl85FOpIrQSeto4W@google.com> (raw)
In-Reply-To: <2-v1-1b720dce51d1+4f44-smmuv3_tidy_jgg@nvidia.com>
Hi Jason,
On Mon, Jun 03, 2024 at 07:31:28PM -0300, Jason Gunthorpe wrote:
> dmam_alloc_coherent() already returns zero'd memory so cfg->strtab.l1_desc
> (the list of DMA addresses for the L2 entries) is already zero'd.
>
> arm_smmu_init_l1_strtab() goes through and calls
> arm_smmu_write_strtab_l1_desc() on the newly allocated (and zero'd) struct
> arm_smmu_strtab_l1_desc, which ends up computing 'val = 0' and zeroing it
> again.
>
> Remove arm_smmu_init_l1_strtab() and just call devm_kcalloc() from
> arm_smmu_init_strtab_2lvl to allocate the companion struct.
>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Looking at the code for dmam_alloc_coherent(basically dma_alloc_coherent)
I see that the memory is zeroed for both DMA direct and IOMMU, however
I don’t see that documented (in DMA-API.txt).
Assuming that’s guaranteed to be zeroed (maybe we should update the docs
if I am not missing something)
Reviewed-by: Mostafa Saleh <smostafa@google.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 27 +++++++--------------
> 1 file changed, 9 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index 6b4f1a664288db..d27dd0600bf1df 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -3220,23 +3220,6 @@ static int arm_smmu_init_queues(struct arm_smmu_device *smmu)
> PRIQ_ENT_DWORDS, "priq");
> }
>
> -static int arm_smmu_init_l1_strtab(struct arm_smmu_device *smmu)
> -{
> - unsigned int i;
> - struct arm_smmu_strtab_cfg *cfg = &smmu->strtab_cfg;
> -
> - cfg->l1_desc = devm_kcalloc(smmu->dev, cfg->num_l1_ents,
> - sizeof(*cfg->l1_desc), GFP_KERNEL);
> - if (!cfg->l1_desc)
> - return -ENOMEM;
> -
> - for (i = 0; i < cfg->num_l1_ents; ++i)
> - arm_smmu_write_strtab_l1_desc(
> - &smmu->strtab_cfg.strtab.l1_desc[i], &cfg->l1_desc[i]);
> -
> - return 0;
> -}
> -
> static int arm_smmu_init_strtab_2lvl(struct arm_smmu_device *smmu)
> {
> void *strtab;
> @@ -3272,7 +3255,15 @@ static int arm_smmu_init_strtab_2lvl(struct arm_smmu_device *smmu)
> reg |= FIELD_PREP(STRTAB_BASE_CFG_SPLIT, STRTAB_SPLIT);
> cfg->strtab_base_cfg = reg;
>
> - return arm_smmu_init_l1_strtab(smmu);
> + cfg->l1_desc = devm_kcalloc(smmu->dev, cfg->num_l1_ents,
> + sizeof(*cfg->l1_desc), GFP_KERNEL);
> + if (!cfg->l1_desc) {
> + dev_err(smmu->dev,
> + "failed to allocate l1 stream table (%zu bytes)\n",
> + cfg->num_l1_ents * sizeof(*cfg->l1_desc));
> + return -ENOMEM;
> + }
> + return 0;
> }
>
> static int arm_smmu_init_strtab_linear(struct arm_smmu_device *smmu)
> --
> 2.45.2
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-06-04 15:56 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-03 22:31 [PATCH 0/7] Tidy some minor things in the stream table/cd table area Jason Gunthorpe
2024-06-03 22:31 ` Jason Gunthorpe
2024-06-03 22:31 ` [PATCH 1/7] iommu/arm-smmu-v3: Split struct arm_smmu_strtab_cfg.strtab Jason Gunthorpe
2024-06-03 22:31 ` Jason Gunthorpe
2024-06-04 8:32 ` Nicolin Chen
2024-06-04 8:32 ` Nicolin Chen
2024-06-04 12:59 ` Jason Gunthorpe
2024-06-04 12:59 ` Jason Gunthorpe
2024-06-04 18:28 ` Nicolin Chen
2024-06-04 18:28 ` Nicolin Chen
2024-06-04 19:02 ` Jason Gunthorpe
2024-06-04 19:02 ` Jason Gunthorpe
2024-06-04 19:28 ` Nicolin Chen
2024-06-04 19:28 ` Nicolin Chen
2024-06-04 15:52 ` Mostafa Saleh
2024-06-04 15:52 ` Mostafa Saleh
2024-06-05 23:51 ` Jason Gunthorpe
2024-06-05 23:51 ` Jason Gunthorpe
2024-06-03 22:31 ` [PATCH 2/7] iommu/arm-smmu-v3: Do not zero the strtab twice Jason Gunthorpe
2024-06-03 22:31 ` Jason Gunthorpe
2024-06-04 15:56 ` Mostafa Saleh [this message]
2024-06-04 15:56 ` Mostafa Saleh
2024-06-05 21:22 ` Jason Gunthorpe
2024-06-05 21:22 ` Jason Gunthorpe
2024-06-03 22:31 ` [PATCH 3/7] iommu/arm-smmu-v3: Shrink the strtab l1_desc array Jason Gunthorpe
2024-06-03 22:31 ` Jason Gunthorpe
2024-06-04 16:01 ` Mostafa Saleh
2024-06-04 16:01 ` Mostafa Saleh
2024-06-03 22:31 ` [PATCH 4/7] iommu/arm-smmu-v3: Split struct arm_smmu_ctx_desc_cfg.cdtab Jason Gunthorpe
2024-06-03 22:31 ` Jason Gunthorpe
2024-06-04 16:07 ` Mostafa Saleh
2024-06-04 16:07 ` Mostafa Saleh
2024-06-06 23:59 ` Jason Gunthorpe
2024-06-06 23:59 ` Jason Gunthorpe
2024-06-03 22:31 ` [PATCH 5/7] iommu/arm-smmu-v3: Do not use devm for the cd table allocations Jason Gunthorpe
2024-06-03 22:31 ` Jason Gunthorpe
2024-06-03 22:31 ` [PATCH 6/7] iommu/arm-smmu-v3: Shrink the cdtab l1_desc array Jason Gunthorpe
2024-06-03 22:31 ` Jason Gunthorpe
2024-06-04 16:14 ` Mostafa Saleh
2024-06-04 16:14 ` Mostafa Saleh
2024-06-03 22:31 ` [PATCH 7/7] iommu/arm-smmu-v3: Use the new rb tree helpers Jason Gunthorpe
2024-06-03 22:31 ` Jason Gunthorpe
2024-06-04 16:22 ` Mostafa Saleh
2024-06-04 16:22 ` Mostafa Saleh
2024-06-03 22:41 ` [PATCH 0/7] Tidy some minor things in the stream table/cd table area Nicolin Chen
2024-06-03 22:41 ` 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=Zl85FOpIrQSeto4W@google.com \
--to=smostafa@google.com \
--cc=iommu@lists.linux.dev \
--cc=jgg@nvidia.com \
--cc=joro@8bytes.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mshavit@google.com \
--cc=nicolinc@nvidia.com \
--cc=patches@lists.linux.dev \
--cc=robin.murphy@arm.com \
--cc=ryan.roberts@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.