lkml.org 
[lkml]   [2023]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH 03/11] dt-bindings: Add RISC-V IOMMU bindings
    On Wed, Aug 16, 2023 at 2:38 AM Jason Gunthorpe <jgg@ziepe.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@ziepe.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

    \
     
     \ /
      Last update: 2023-08-16 04:18    [W:6.565 / U:0.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site