From: Pranjal Shrivastava <praan@google.com>
To: Peng Fan <peng.fan@nxp.com>
Cc: Robin Murphy <robin.murphy@arm.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
"Peng Fan (OSS)" <peng.fan@oss.nxp.com>,
Will Deacon <will@kernel.org>, 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"
<linux-arm-kernel@lists.infradead.org>,
"iommu@lists.linux.dev" <iommu@lists.linux.dev>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RFC 2/2] iommu/arm-smmu-v3: Bypass SID0 for NXP i.MX95
Date: Wed, 16 Oct 2024 09:12:04 +0000 [thread overview]
Message-ID: <Zw-DZF4B4psiat59@google.com> (raw)
In-Reply-To: <PAXPR04MB8459EC5B8A55E7FF10E550AC88462@PAXPR04MB8459.eurprd04.prod.outlook.com>
On Wed, Oct 16, 2024 at 09:02:39AM +0000, Peng Fan wrote:
> All,
>
> > Subject: Re: [PATCH RFC 2/2] iommu/arm-smmu-v3: Bypass SID0 for
> > NXP i.MX95
>
> Thanks for the discussion on this topic to show much information
> that I not foresee.
>
> >
> > On Tue, Oct 15, 2024 at 04:37:25PM +0100, Robin Murphy wrote:
> > > On 2024-10-15 4:31 pm, Jason Gunthorpe wrote:
> > > > On Tue, Oct 15, 2024 at 04:13:13PM +0100, Robin Murphy wrote:
> > > > > On 2024-10-15 1:47 pm, 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.
> > > > >
> > > > > There is no domain, this is bypassing an arbitrary StreamID not
> > > > > associated with any device.
> > > >
> > > > If the stream ID is going to flow traffic shouldn't it have a DT
> > > > node for it? Something must be driving the DMA on this SID, and
> > the
> > > > kernel does need to know what that is in some way, even for basic
> > > > security things like making sure VFIO doesn't get a hold of it :\
> > >
> > > Exactly, hence this RFC is definitely not the right approach.
> >
> > Agreed. I assumed the bypass was needed for a registered SID.
>
> I just reply here, not reply each thread.
Apologies, I responded to the other thread before looking at this one
>
> The SID is not a registered SID.
>
> Considering the security things, except "iommus = <&smmu 0>"
> being added, is there other method for this issue?
I can only think of RMRs if you can ensure/restrict eDMA3 to access a
fixed region of memory. Something like a DMA zone if feasible.
>
> Thanks,
> Peng.
>
> >
> > >
> > > Thanks,
> > > Robin.
> >
Thanks,
Pranjal
next prev parent reply other threads:[~2024-10-16 9:12 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
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 [this message]
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=Zw-DZF4B4psiat59@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.