From: Pranjal Shrivastava <praan@google.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: "Peng Fan (OSS)" <peng.fan@oss.nxp.com>,
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>
Subject: Re: [PATCH RFC 2/2] iommu/arm-smmu-v3: Bypass SID0 for NXP i.MX95
Date: Tue, 15 Oct 2024 15:07:32 +0000 [thread overview]
Message-ID: <Zw6FNCACa03nE5Cx@google.com> (raw)
In-Reply-To: <Zw6DekI9X7lL4f1G@google.com>
On Tue, Oct 15, 2024 at 03:00:10PM +0000, Pranjal Shrivastava wrote:
> On Tue, Oct 15, 2024 at 09:47:23AM -0300, Jason Gunthorpe wrote:
> > On Tue, Oct 15, 2024 at 08:13:28AM +0000, Pranjal Shrivastava wrote:
> >
> > > 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?
> >
> > Yeah, that is the expected way, to force the def_domain_type to
> > IDENTITY and refuse to attach a PAGING/BLOCKED domain.
> >
> > If this is a common thing we could have the core code take on more of
> > the job.
>
> Yes! I've seen the IOMMU being bypassed at multiple places, primarily
> for performance, people like bypassing the iommu for "trusted" devices.
> A few examples that are publically accessible: Qcomm SoCs [1], [2].
> Seems like Qualcomm have a DT property `qcomm-s1-bypass` to achieve
> something similar.
>
> In fact, *blast from the past*, I tried to do something similar sometime
> ago with [3]. Although, perhaps that wasn't the best way (and I was a
> kernel newbie :))
>
> A little off-topic, but I think there has been some interest to bypass
> the default substream as well while still maintaining PASID isolation.[4]
>
Agh, apologies, ignore the following part about rmr,
it won't solve the problem here.
> Although, as far as arm-smmu-v3 is concerned, IIRC, I think there was a
> way to tell that the region is reserved and don't map it.
>
> >
> > Jason
>
> Thanks,
> Pranjal
>
> [1]
> https://github.com/realme-kernel-opensource/realme5-kernel-source/blob/master/arch/arm64/boot/dts/qcom/sa8155-vm-qupv3.dtsi#L22
>
> [2]
> https://android.googlesource.com/kernel/msm/+/android-7.1.0_r0.2/Documentation/devicetree/bindings/platform/msm/ipa.txt#28
>
> [3]
> https://lore.kernel.org/all/20230707104857.348353-1-praan@google.com/
>
> [4]
> https://lore.kernel.org/all/CAGfWUPziSWNMc_px4E-i+_V_Jxdb_WSwOLXHZ+PANz2Tv5pFPA@mail.gmail.com/
next prev parent reply other threads:[~2024-10-15 15:07 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
2024-10-15 12:47 ` Jason Gunthorpe
2024-10-15 15:00 ` Pranjal Shrivastava
2024-10-15 15:07 ` Pranjal Shrivastava [this message]
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=Zw6FNCACa03nE5Cx@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 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.