From: Pranjal Shrivastava <praan@google.com>
To: "Peng Fan (OSS)" <peng.fan@oss.nxp.com>
Cc: Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
Joerg Roedel <joro@8bytes.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>, Joy Zou <joy.zou@nxp.com>,
linux-arm-kernel@lists.infradead.org, iommu@lists.linux.dev,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Peng Fan <peng.fan@nxp.com>, Jason Gunthorpe <jgg@ziepe.ca>
Subject: Re: [PATCH RFC 2/2] iommu/arm-smmu-v3: Bypass SID0 for NXP i.MX95
Date: Tue, 15 Oct 2024 08:13:28 +0000 [thread overview]
Message-ID: <Zw4kKDFOcXEC78mb@google.com> (raw)
In-Reply-To: <20241015-smmuv3-v1-2-e4b9ed1b5501@nxp.com>
On Tue, Oct 15, 2024 at 11:14:43AM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> i.MX95 eDMA3 connects to DSU ACP, supporting dma coherent memory to
> memory operations. However TBU is in the path between eDMA3 and ACP,
> need to bypass the default SID 0 to make eDMA3 work properly.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 19 ++++++++++++++++---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 +
> 2 files changed, 17 insertions(+), 3 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 737c5b88235510e3ddb91a28cecbdcdc14854b32..3db7b3e2ac94e16130fc0356f7954ffa1a9dfb33 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -80,6 +80,7 @@ DEFINE_MUTEX(arm_smmu_asid_lock);
> static struct arm_smmu_option_prop arm_smmu_options[] = {
> { ARM_SMMU_OPT_SKIP_PREFETCH, "hisilicon,broken-prefetch-cmd" },
> { ARM_SMMU_OPT_PAGE0_REGS_ONLY, "cavium,cn9900-broken-page1-regspace"},
> + { ARM_SMMU_OPT_IMX95_BYPASS_SID0, "nxp,imx95-bypass-sid-zero"},
> { 0, NULL},
> };
Aghh, let's not put HW-specific bypass under `arm_smmu_options`.
Otherwise, this might become a huge list of SoCs wanting to bypass SIDs.
>
> @@ -4465,7 +4466,7 @@ static void __iomem *arm_smmu_ioremap(struct device *dev, resource_size_t start,
> return devm_ioremap_resource(dev, &res);
> }
>
> -static void arm_smmu_rmr_install_bypass_ste(struct arm_smmu_device *smmu)
> +static void arm_smmu_install_bypass_ste(struct arm_smmu_device *smmu)
> {
> struct list_head rmr_list;
> struct iommu_resv_region *e;
> @@ -4496,6 +4497,18 @@ static void arm_smmu_rmr_install_bypass_ste(struct arm_smmu_device *smmu)
> }
>
> iort_put_rmr_sids(dev_fwnode(smmu->dev), &rmr_list);
> +
> + if (smmu->options & ARM_SMMU_OPT_IMX95_BYPASS_SID0) {
> + int ret = arm_smmu_init_sid_strtab(smmu, 0);
> +
> + if (ret) {
> + dev_err(smmu->dev, "i.MX95 SID0 bypass failed\n");
> + return;
> + }
> +
> + arm_smmu_make_bypass_ste(smmu,
> + arm_smmu_get_step_for_sid(smmu, 0));
> + }
> }
Umm.. this was specific for rmr not a generic thing. I'd suggest to
avoid meddling with the STEs directly for acheiving bypass. Playing
with the iommu domain type could be neater. Perhaps, modify the
ops->def_domain_type to return an appropriate domain?
In general, adding a property/config for bypassing SIDs/devices could
potentially cause security concerns if *somehow* a device can spoof an
SID. For example, if a PCIe device is bypassed it would be easy for
another PCIe endpoint to spoof it's ID. Similarly, certain HW
implementations may provide the option to programmable SIDs, for
example, a HW register to set SIDs, which if compromised can spoof other
SIDs. Although, I'd like to see what the others think about this.
>
> static void arm_smmu_impl_remove(void *data)
> @@ -4614,8 +4627,8 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
> /* Record our private device structure */
> platform_set_drvdata(pdev, smmu);
>
> - /* Check for RMRs and install bypass STEs if any */
> - arm_smmu_rmr_install_bypass_ste(smmu);
> + /* Install bypass STEs if any */
> + arm_smmu_install_bypass_ste(smmu);
>
> /* Reset the device */
> ret = arm_smmu_device_reset(smmu);
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> index 1e9952ca989f87957197f4d4b400f9d74bb685ac..06481b923284776e7dc4f3301e5cbe8ab7869a9c 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> @@ -733,6 +733,7 @@ struct arm_smmu_device {
> #define ARM_SMMU_OPT_MSIPOLL (1 << 2)
> #define ARM_SMMU_OPT_CMDQ_FORCE_SYNC (1 << 3)
> #define ARM_SMMU_OPT_TEGRA241_CMDQV (1 << 4)
> +#define ARM_SMMU_OPT_IMX95_BYPASS_SID0 (1 << 5)
> u32 options;
>
> struct arm_smmu_cmdq cmdq;
>
> --
> 2.37.1
>
>
Thanks,
Pranjal
next prev parent reply other threads:[~2024-10-15 8:13 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-15 3:14 [PATCH RFC 0/2] iommu/arm-smmu-v3: bypass streamid zero on i.MX95 Peng Fan (OSS)
2024-10-15 3:14 ` [PATCH RFC 1/2] dt-bindings: iommu: arm,smmu-v3: introduce nxp,imx95-bypass-sid-zero Peng Fan (OSS)
2024-10-15 3:14 ` [PATCH RFC 2/2] iommu/arm-smmu-v3: Bypass SID0 for NXP i.MX95 Peng Fan (OSS)
2024-10-15 8:13 ` Pranjal Shrivastava [this message]
2024-10-15 12:47 ` Jason Gunthorpe
2024-10-15 15:00 ` Pranjal Shrivastava
2024-10-15 15:07 ` Pranjal Shrivastava
2024-10-15 15:24 ` Jason Gunthorpe
2024-10-15 15:13 ` Robin Murphy
2024-10-15 15:19 ` Pranjal Shrivastava
2024-10-15 15:31 ` Jason Gunthorpe
2024-10-15 15:37 ` Robin Murphy
2024-10-15 16:10 ` Pranjal Shrivastava
2024-10-16 9:02 ` Peng Fan
2024-10-16 9:12 ` Pranjal Shrivastava
2024-10-15 7:45 ` [PATCH RFC 0/2] iommu/arm-smmu-v3: bypass streamid zero on i.MX95 Pranjal Shrivastava
2024-10-15 14:47 ` Robin Murphy
2024-10-16 0:56 ` Peng Fan
2024-10-16 1:15 ` Nicolin Chen
2024-10-16 8:53 ` Peng Fan
2024-10-16 9:06 ` Pranjal Shrivastava
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=Zw4kKDFOcXEC78mb@google.com \
--to=praan@google.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=iommu@lists.linux.dev \
--cc=jgg@ziepe.ca \
--cc=joro@8bytes.org \
--cc=joy.zou@nxp.com \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peng.fan@nxp.com \
--cc=peng.fan@oss.nxp.com \
--cc=robh@kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).