linux-kernel - Re: [PATCH v3 00/22] riscv: Memory type control for platforms with physical memory aliases

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: <7cfd85f6-54e9-42df-8330-d81fbe441ca5@kernel.org>
Date: Thu, 13 Nov 2025 20:13:52 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Samuel Holland <samuel.holland@...ive.com>,
 Palmer Dabbelt <palmer@...belt.com>, Paul Walmsley <pjw@...nel.org>,
 linux-riscv@...ts.infradead.org, Andrew Morton <akpm@...ux-foundation.org>,
 linux-mm@...ck.org
Cc: devicetree@...r.kernel.org, Suren Baghdasaryan <surenb@...gle.com>,
 linux-kernel@...r.kernel.org, Mike Rapoport <rppt@...nel.org>,
 Michal Hocko <mhocko@...e.com>, Conor Dooley <conor@...nel.org>,
 Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Alexandre Ghiti <alex@...ti.fr>,
 Emil Renner Berthing <kernel@...il.dk>, Rob Herring <robh+dt@...nel.org>,
 Vlastimil Babka <vbabka@...e.cz>, "Liam R . Howlett"
 <Liam.Howlett@...cle.com>, Andy Whitcroft <apw@...onical.com>,
 Dwaipayan Ray <dwaipayanray1@...il.com>, Joe Perches <joe@...ches.com>,
 Julia Lawall <Julia.Lawall@...ia.fr>, Lukas Bulwahn
 <lukas.bulwahn@...il.com>, Nicolas Palix <nicolas.palix@...g.fr>
Subject: Re: [PATCH v3 00/22] riscv: Memory type control for platforms with
 physical memory aliases

On 13.11.25 02:45, Samuel Holland wrote:
> 
> On some RISC-V platforms, including StarFive JH7100 and ESWIN EIC7700,
> DRAM is mapped to multiple physical address ranges, with each alias
> having a different set of statically-determined Physical Memory
> Attributes (PMAs), such as cacheability. Software can alter the PMAs for
> a page by selecting a PFN from the corresponding physical address range.
> On these platforms, this is the only way to allocate noncached memory
> for use with noncoherent DMA.
> 
> These physical memory aliases are only visible to architecture code.
> Generic MM code only ever sees the primary (cacheable) alias. The major
> change from v1 of this series is that I was asked to move the hooks from
> pfn_pXX()/pXX_pfn() to set_pXX()/pXXp_get().
> 
>   - Patches 1-10 ensure that architecture-specific code that hooks page
>     table reads and writes is always called, and the calls are balanced.

It is not immediately clear to me from the description why that is 
required. Can you summarize the core problem here, and why we have to 
route everything through these accessors?

-- 
Cheers

David