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: <20210527113456.GA22019@willie-the-truck>
Date:   Thu, 27 May 2021 12:34:57 +0100
From:   Will Deacon <will@...nel.org>
To:     Claire Chang <tientzu@...omium.org>
Cc:     heikki.krogerus@...ux.intel.com, thomas.hellstrom@...ux.intel.com,
        peterz@...radead.org, benh@...nel.crashing.org,
        joonas.lahtinen@...ux.intel.com, dri-devel@...ts.freedesktop.org,
        chris@...is-wilson.co.uk, grant.likely@....com, paulus@...ba.org,
        Frank Rowand <frowand.list@...il.com>, mingo@...nel.org,
        sstabellini@...nel.org, Saravana Kannan <saravanak@...gle.com>,
        mpe@...erman.id.au,
        "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>,
        Christoph Hellwig <hch@....de>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        bskeggs@...hat.com, linux-pci@...r.kernel.org,
        xen-devel@...ts.xenproject.org,
        Thierry Reding <treding@...dia.com>,
        intel-gfx@...ts.freedesktop.org, matthew.auld@...el.com,
        linux-devicetree <devicetree@...r.kernel.org>,
        Jianxiong Gao <jxgao@...gle.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        maarten.lankhorst@...ux.intel.com, airlied@...ux.ie,
        Dan Williams <dan.j.williams@...el.com>,
        linuxppc-dev@...ts.ozlabs.org, jani.nikula@...ux.intel.com,
        Rob Herring <robh+dt@...nel.org>, rodrigo.vivi@...el.com,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        boris.ostrovsky@...cle.com,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        jgross@...e.com, Nicolas Boichat <drinkcat@...omium.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        lkml <linux-kernel@...r.kernel.org>,
        "list@....net:IOMMU DRIVERS" <iommu@...ts.linux-foundation.org>,
        Jim Quinlan <james.quinlan@...adcom.com>, xypron.glpk@....de,
        Robin Murphy <robin.murphy@....com>, bauerman@...ux.ibm.com
Subject: Re: [PATCH v7 14/15] dt-bindings: of: Add restricted DMA pool

On Thu, May 27, 2021 at 07:29:20PM +0800, Claire Chang wrote:
> On Wed, May 26, 2021 at 11:53 PM Will Deacon <will@...nel.org> wrote:
> >
> > On Wed, May 26, 2021 at 01:13:22PM +0100, Will Deacon wrote:
> > > On Tue, May 18, 2021 at 02:42:14PM +0800, Claire Chang wrote:
> > > > @@ -138,4 +160,9 @@ one for multimedia processing (named multimedia-memory@...00000, 64MiB).
> > > >             memory-region = <&multimedia_reserved>;
> > > >             /* ... */
> > > >     };
> > > > +
> > > > +   pcie_device: pcie_device@0,0 {
> > > > +           memory-region = <&restricted_dma_mem_reserved>;
> > > > +           /* ... */
> > > > +   };
> > >
> > > I still don't understand how this works for individual PCIe devices -- how
> > > is dev->of_node set to point at the node you have above?
> > >
> > > I tried adding the memory-region to the host controller instead, and then
> > > I see it crop up in dmesg:
> > >
> > >   | pci-host-generic 40000000.pci: assigned reserved memory node restricted_dma_mem_reserved
> > >
> > > but none of the actual PCI devices end up with 'dma_io_tlb_mem' set, and
> > > so the restricted DMA area is not used. In fact, swiotlb isn't used at all.
> > >
> > > What am I missing to make this work with PCIe devices?
> >
> > Aha, looks like we're just missing the logic to inherit the DMA
> > configuration. The diff below gets things working for me.
> 
> I guess what was missing is the reg property in the pcie_device node.
> Will update the example dts.

Thanks. I still think something like my diff makes sense, if you wouldn't mind including
it, as it allows restricted DMA to be used for situations where the PCIe
topology is not static.

Perhaps we should prefer dev->of_node if it exists, but then use the node
of the host bridge's parent node otherwise?

Will

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ