[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANXhq0pQ5wisNtbVjm031btUiO=y_MmA9rfbWwnMFo_1y2d50w@mail.gmail.com>
Date: Wed, 16 Aug 2023 10:16:36 +0800
From: Zong Li <zong.li@...ive.com>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: Baolu Lu <baolu.lu@...ux.intel.com>,
Anup Patel <apatel@...tanamicro.com>,
Tomasz Jeznach <tjeznach@...osinc.com>,
Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>,
Robin Murphy <robin.murphy@....com>,
Paul Walmsley <paul.walmsley@...ive.com>,
Albert Ou <aou@...s.berkeley.edu>, linux@...osinc.com,
linux-kernel@...r.kernel.org, Sebastien Boeuf <seb@...osinc.com>,
iommu@...ts.linux.dev, Palmer Dabbelt <palmer@...belt.com>,
Nick Kossifidis <mick@....forth.gr>,
linux-riscv@...ts.infradead.org
Subject: Re: [PATCH 03/11] dt-bindings: Add RISC-V IOMMU bindings
On Wed, Aug 16, 2023 at 2:38 AM Jason Gunthorpe <jgg@...pe.ca> wrote:
>
> On Tue, Aug 15, 2023 at 09:28:54AM +0800, Zong Li wrote:
> > On Wed, Aug 9, 2023 at 10:57 PM Jason Gunthorpe <jgg@...pe.ca> wrote:
> > >
> > > On Thu, Jul 27, 2023 at 10:42:47AM +0800, Zong Li wrote:
> > >
> > > > Perhaps this question could be related to the scenarios in which
> > > > devices wish to be in bypass mode when the IOMMU is in translation
> > > > mode, and why IOMMU defines/supports this case. Currently, I could
> > > > envision a scenario where a device is already connected to the IOMMU
> > > > in hardware, but it is not functioning correctly, or there are
> > > > performance impacts. If modifying the hardware is not feasible, a
> > > > default configuration that allows bypass mode could be provided as a
> > > > solution. There might be other scenarios that I might have overlooked.
> > > > It seems to me since IOMMU supports this configuration, it would be
> > > > advantageous to have an approach to achieve it, and DT might be a
> > > > flexible way.
> > >
> > > So far we've taken the approach that broken hardware is quirked in the
> > > kernel by matching OF compatible string pattners. This is HW that is
> > > completely broken and the IOMMU doesn't work at all for it.
> > >
> > > HW that is slow or whatever is not quirked and this is an admin policy
> > > choice where the system should land on the security/performance
> > > spectrum.
> > >
> > > So I'm not sure adding DT makes sense here.
> > >
> >
> > Hi Jason,
> > Sorry for being late here, I hadn't noticed this reply earlier. The
> > approach seems to address the situation. Could you kindly provide
> > information about the location of the patches? I was wondering about
> > further details regarding this particular implementation. Thanks
>
> There are a couple versions, eg
> arm_smmu_def_domain_type()
> qcom_smmu_def_domain_type()
>
I thought what you mentioned earlier is that there is a new approach
being considered for this. I think what you point out is the same as
Anup mentioned. However, as I mentioned earlier, I am exploring a more
flexible approach to achieve this objective. This way, we can avoid
hard coding anything (i.e.list compatible string) in the driver or
requiring a kernel rebuild every time we need to change the mode for
specific devices. For example, the driver could parse the device node
to determine and record if a device will be set to bypass, and then
the .def_domain_type could be used to set to IOMMU_DOMAIN_IDENTITY by
the record. I'm not sure if it makes sense for everyone, it seems to
me that it would be great if there is a way to do this. :)
> Jason
Powered by blists - more mailing lists