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]
Date:   Fri, 10 Mar 2023 12:12:01 +0000
From:   Marc Zyngier <maz@...nel.org>
To:     Peter Geis <pgwipeout@...il.com>
Cc:     Lucas Tanure <lucas.tanure@...labora.com>,
        Vinod Koul <vkoul@...nel.org>,
        Kishon Vijay Abraham I <kishon@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Heiko Stuebner <heiko@...ech.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        Lorenzo Pieralisi <lpieralisi@...nel.org>,
        Krzysztof Wilczynski <kw@...ux.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>, Qu Wenruo <wqu@...e.com>,
        Piotr Oniszczuk <piotr.oniszczuk@...il.com>,
        Kever Yang <kever.yang@...k-chips.com>,
        linux-phy@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-pci@...r.kernel.org, kernel@...labora.com,
        Robin Murphy <robin.murphy@....com>
Subject: Re: [PATCH 1/7] irqchip/gic-v3: Add a DMA Non-Coherent flag

On Fri, 10 Mar 2023 12:04:16 +0000,
Peter Geis <pgwipeout@...il.com> wrote:
> 
> On Fri, Mar 10, 2023 at 6:57 AM Marc Zyngier <maz@...nel.org> wrote:
> >
> > On Fri, 10 Mar 2023 11:41:46 +0000,
> > Peter Geis <pgwipeout@...il.com> wrote:
> > >
> > > On Fri, Mar 10, 2023 at 3:05 AM Lucas Tanure <lucas.tanure@...labora.com> wrote:
> > > >
> > > > The GIC600 integration in RK356x, used in rk3588, doesn't support
> > > > any of the shareability or cacheability attributes, and requires
> > > > both values to be set to 0b00 for all the ITS and Redistributor
> > > > tables.
> > > >
> > > > This is loosely based on prior work from XiaoDong Huang and
> > > > Peter Geis fixing this issue specifically for Rockchip 356x.
> > >
> > > Good Morning,
> > >
> > > Since the gic is using dma, would it be reasonable to have all memory
> > > allocations be requested with the GFP_DMA flag? Otherwise this doesn't
> > > fully solve the problem for rk356x, where only the lower 4GB range is
> > > DMA capable, but this tends to get allocated in the upper 4GB on 8GB
> > > boards.
> >
> > That's an erratum. Please treat as such.
> 
> Good Morning,
> 
> Yes, believe me I'm fully aware of how broken rk356x is. I'm asking an
> educational question from a kernel standards point of view, absent the
> rk356x issues. Would it be reasonable that since the gic uses dma
> memory, allocations for the gic should be made with the GFP_DMA flag?
> Or is that a misuse of the flag?

As Robin points out in another part of the thread, the right fix would
be to convert the ITS as a pure platform driver and handle the probing
dependencies that this would generate. Then you can start making us of
the DMA allocator and of the firmware description of what ranges are
reachable from the GIC (although this isn't strictly the ITS, but
also the redistributors).

We're in a better place for this now than we were a few years ago, but
this is still a sizeable amount of work.

If someone is motivated enough, they can have a go at it.

	M.

-- 
Without deviation from the norm, progress is not possible.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ