linux-kernel - Re: [PATCH 0/6] RISC-V: Add eMMC support for TH1520 boards

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:   Wed, 04 Oct 2023 22:58:52 +0800
From:   Icenowy Zheng <uwu@...nowy.me>
To:     Robin Murphy <robin.murphy@....com>,
        "Lad, Prabhakar" <prabhakar.csengg@...il.com>,
        Jisheng Zhang <jszhang@...nel.org>
Cc:     Drew Fustini <dfustini@...libre.com>,
        Christoph Hellwig <hch@....de>,
        Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>,
        Robert Nelson <robertcnelson@...il.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Guo Ren <guoren@...nel.org>, Fu Wei <wefu@...hat.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Conor Dooley <conor@...nel.org>,
        Jason Kridner <jkridner@...gleboard.org>,
        Xi Ruoyao <xry111@...111.site>, Han Gao <gaohan@...as.ac.cn>,
        linux-mmc@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org,
        Björn Töpel <bjorn@...nel.org>,
        Alexandre Ghiti <alexghiti@...osinc.com>,
        Linux-MM <linux-mm@...ck.org>
Subject: Re: [PATCH 0/6] RISC-V: Add eMMC support for TH1520 boards

在 2023-10-04星期三的 15:18 +0100，Robin Murphy写道：
> On 04/10/2023 3:02 pm, Icenowy Zheng wrote:
> [...]
> > > > > I believe commit 484861e09f3e ("soc: renesas: Kconfig: Select
> > > > > the
> > > > > required configs for RZ/Five SoC") can cause regression on
> > > > > all
> > > > > non-dma-coherent riscv platforms with generic defconfig. This
> > > > > is
> > > > > a common issue. The logic here is: generic riscv defconfig
> > > > > selects
> > > > > ARCH_R9A07G043 which selects DMA_GLOBAL_POOL, which assumes
> > > > > all
> > > > > non-dma-coherent riscv platforms have a dma global pool, this
> > > > > assumption
> > > > > seems not correct. And I believe DMA_GLOBAL_POOL should not
> > > > > be
> > > > > selected by ARCH_SOCFAMILIY, instead, only ARCH under some
> > > > > specific
> > > > > conditions can select it globaly, for example NOMMU ARM and
> > > > > so
> > > > > on.
> > > > > 
> > > > > Since this is a regression, what's proper fix? any suggestion
> > > > > is
> > > > > appreciated.
> > > 
> > > I think the answer is to not select DMA_GLOBAL_POOL, since that
> > > is
> > > only
> > 
> > Well I think for RISC-V, it's not NOMMU only but applicable for
> > every
> > core that does not support Svpbmt or vendor-specific alternatives,
> > because the original RISC-V priv spec does not define memory
> > attributes
> > in page table entries.
> > 
> > For the Renesas/Andes case I think a pool is set by OpenSBI with
> > vendor-specific M-mode facility and then passed in DT, and the S-
> > mode
> > (which MMU is enabled in) just sees fixed memory attributes, in
> > this
> > case I think DMA_GLOBAL_POOL is needed.
> 
> Oh wow, is that really a thing? In that case, either you just can't 
> support this platform in a multi-platform kernel, or someone needs to
> do 

Well, considering RZ/Five enables some spec-non-conformant local memory
(which bypasses MMU) that makes even running generic user space
binaries not so viable (PIE ones may still run, but those built to be
on the default fixed location of binutils will conflict with the MMU-
bypassing local memory), not supporting it in a multi-platform kernel
doesn't look like a big deal.

> some fiddly work in dma-direct to a) introduce the notion of an
> optional 
> global pool, and b) make it somehow cope with DMA_DIRECT_REMAP being 
> enabled but non-functional.
> 
> Thanks,
> Robin.