lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANXhq0qMWS_j0n_aUO8BVFSedYCjuMM=Z_tsnK05ZhG+Ob6pqw@mail.gmail.com>
Date:   Thu, 27 Jul 2023 10:42:47 +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, Jul 26, 2023 at 8:17 PM Jason Gunthorpe <jgg@...pe.ca> wrote:
>
> On Wed, Jul 26, 2023 at 12:26:14PM +0800, Zong Li wrote:
> > On Wed, Jul 26, 2023 at 11:21 AM Baolu Lu <baolu.lu@...ux.intel.com> wrote:
> > >
> > > On 2023/7/24 21:23, Zong Li wrote:
> > > >>>>> In RISC-V IOMMU, certain devices can be set to bypass mode when the
> > > >>>>> IOMMU is in translation mode. To identify the devices that require
> > > >>>>> bypass mode by default, does it be sensible to add a property to
> > > >>>>> indicate this behavior?
> > > >>>> Bypass mode for a device is a property of that device (similar to dma-coherent)
> > > >>>> and not of the IOMMU. Other architectures (ARM and x86) never added such
> > > >>>> a device property for bypass mode so I guess it is NOT ADVISABLE to do it.
> > > >>>>
> > > >>>> If this is REALLY required then we can do something similar to the QCOM
> > > >>>> SMMU driver where they have a whitelist of devices which are allowed to
> > > >>>> be in bypass mode (i.e. IOMMU_DOMAIN_IDENTITY) based their device
> > > >>>> compatible string and any device outside this whitelist is
> > > >>>> blocked by default.
>
> I have a draft patch someplace that consolidated all this quirk
> checking into the core code. Generally the expectation is that any
> device behind an iommu is fully functional in all modes. The existing
> quirks are for HW defects that make some devices not work properly. In
> this case the right outcome seems to be effectively blocking them from
> using the iommu.
>
> So, you should explain a lot more what "require bypass mode" means in
> the RISCV world and why any device would need it.

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.

>
> Jason

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ