All of lore.kernel.org
 help / color / mirror / Atom feed
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:00:10 +0000	[thread overview]
Message-ID: <Zw6DekI9X7lL4f1G@google.com> (raw)
In-Reply-To: <20241015124723.GI1825128@ziepe.ca>

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]

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/

  reply	other threads:[~2024-10-15 15:00 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 [this message]
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=Zw6DekI9X7lL4f1G@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.