linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh@kernel.org>
To: Samuel Holland <samuel.holland@sifive.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Walmsley <pjw@kernel.org>,
	linux-riscv@lists.infradead.org,
	Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@redhat.com>,
	linux-mm@kvack.org, devicetree@vger.kernel.org,
	Suren Baghdasaryan <surenb@google.com>,
	linux-kernel@vger.kernel.org, Mike Rapoport <rppt@kernel.org>,
	Michal Hocko <mhocko@suse.com>, Conor Dooley <conor@kernel.org>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Emil Renner Berthing <kernel@esmil.dk>,
	Vlastimil Babka <vbabka@suse.cz>,
	"Liam R . Howlett" <Liam.Howlett@oracle.com>
Subject: Re: [PATCH v3 19/22] dt-bindings: riscv: Describe physical memory regions
Date: Thu, 4 Dec 2025 09:12:32 -0600	[thread overview]
Message-ID: <20251204151232.GA1394051-robh@kernel.org> (raw)
In-Reply-To: <20251113014656.2605447-20-samuel.holland@sifive.com>

On Wed, Nov 12, 2025 at 05:45:32PM -0800, Samuel Holland wrote:
> Information about physical memory regions is needed by both the kernel
> and M-mode firmware. For example, the kernel needs to know about
> noncacheable aliases of cacheable memory in order to allocate coherent
> memory pages for DMA. M-mode firmware needs to know about those aliases
> so it can protect itself from lower-privileged software.
> 
> The RISC-V Privileged Architecture delegates the description of Physical
> Memory Attributes (PMAs) to the platform. On DT-based platforms, it
> makes sense to put this information in the devicetree.

I'm not sure how I feel about this. So here are my random thoughts on 
it.

I wonder if another arch may need something similar. I don't think 
arm64 ever would as aliases are not allowed. That may have happened on 
arm32, but that's all pretty mature at this point. I don't know about 
powerpc. I didn't find anything looking similar from a quick search.

Can this property go in the 'memory' nodes instead since the aliases are 
only for DRAM or main memory?

The /reserved-memory nodes you remove do look like an abuse of 
/reserved-memory.


Alternatively, I think you could solve this by using 3 address cells 
similar to how PCI bus bindings work.

memory {
	reg = <0x0 0x80000000 0x0 0x40000000>
	#address-cells = <3>;
	#size-cells = <2>;
	ranges = <PMA_foo 0x0 0x80000000 0x1 0x00000000 0x0 0x40000000>,
		...
}

So CPU address 0x1_00000000 maps to memory address 0x80000000 with 
attributes PMA_foo.

Not sure if you would have to change the dma-ranges in this case. I 
would think not.


> Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
> ---
> 
> Changes in v3:
>  - Split PMR_IS_ALIAS flag from PMR_ALIAS_MASK number
>  - Add "model" property to DT binding example to fix validation
> 
> Changes in v2:
>  - Remove references to Physical Address Width (no longer part of Smmpt)
>  - Remove special first entry from the list of physical memory regions
>  - Fix compatible string in DT binding example
> 
>  .../bindings/riscv/physical-memory.yaml       | 92 +++++++++++++++++++
>  include/dt-bindings/riscv/physical-memory.h   | 45 +++++++++
>  2 files changed, 137 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/riscv/physical-memory.yaml
>  create mode 100644 include/dt-bindings/riscv/physical-memory.h
> 
> diff --git a/Documentation/devicetree/bindings/riscv/physical-memory.yaml b/Documentation/devicetree/bindings/riscv/physical-memory.yaml
> new file mode 100644
> index 000000000000..8beaa588c71c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/riscv/physical-memory.yaml
> @@ -0,0 +1,92 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/riscv/physical-memory.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: RISC-V Physical Memory Regions
> +
> +maintainers:
> +  - Samuel Holland <samuel.holland@sifive.com>
> +
> +description:

You need a '>' for paragraphs.

> +  The RISC-V Privileged Architecture defines a number of Physical Memory
> +  Attributes (PMAs) which apply to a given region of memory. These include the
> +  types of accesses (read, write, execute, LR/SC, and/or AMO) allowed within
> +  a region, the supported access widths and alignments, the cacheability and
> +  coherence of the region, and whether or not accesses to the region may have
> +  side effects.
> +
> +  Some RISC-V platforms provide multiple physical address mappings for main
> +  memory or certain peripherals. Each alias of a region generally has different
> +  PMAs (e.g. cacheable vs non-cacheable), which allows software to dynamically
> +  select the PMAs for an access by referencing the corresponding alias.
> +

> +  On DT-based RISC-V platforms, this information is provided by the
> +  riscv,physical-memory-regions property of the root node.

That's kind of obvious. This document only applies to DT systems and the 
schema defines everything else you say.

> +
> +properties:
> +  $nodename:
> +    const: '/'
> +
> +  riscv,physical-memory-regions:
> +    $ref: /schemas/types.yaml#/definitions/uint32-matrix
> +    description:
> +      Each table entry provides PMAs for a specific physical memory region,
> +      which must not overlap with any other table entry.
> +    minItems: 1
> +    maxItems: 256
> +    items:
> +      minItems: 4
> +      maxItems: 6
> +      additionalItems: true
> +      items:
> +        - description: CPU physical address (#address-cells)
> +        - description: >
> +            Size (#size-cells). For entry 0, if the size is zero, the size is
> +            assumed to be 2^(32 * #size-cells).
> +        - description: >
> +            Flags describing the most restrictive PMAs for any address within
> +            the region.
> +
> +            The least significant byte indicates the types of accesses allowed
> +            for this region. Note that a memory region may support a type of
> +            access (e.g. AMOs) even if the CPU does not.
> +
> +            The next byte describes the cacheability, coherence, idempotency,
> +            and ordering PMAs for this region. It also includes a flag to
> +            indicate that accesses to a region are unsafe and must be
> +            prohibited by software (for example using PMPs or Smmpt).
> +
> +            The third byte is reserved for future PMAs.
> +
> +            The most significant byte is the index of the lowest-numbered entry
> +            which this entry is an alias of, if any. Aliases need not be the
> +            same size, for example if a smaller memory region repeats within a
> +            larger alias.
> +        - description: Reserved for describing future PMAs
> +
> +additionalProperties: true
> +
> +examples:
> +  - |
> +    #include <dt-bindings/riscv/physical-memory.h>
> +
> +    / {
> +      compatible = "beagle,beaglev-starlight-jh7100-r0", "starfive,jh7100";
> +      model = "BeagleV Starlight Beta";
> +      #address-cells = <2>;
> +      #size-cells = <2>;
> +
> +      riscv,physical-memory-regions =
> +          <0x00 0x18000000 0x00 0x00020000 (PMA_RWX | PMA_NONCACHEABLE_MEMORY) 0x0>,
> +          <0x00 0x18080000 0x00 0x00020000 (PMA_RWX | PMA_NONCACHEABLE_MEMORY) 0x0>,
> +          <0x00 0x41000000 0x00 0x1f000000 (PMA_RWX | PMA_NONCACHEABLE_MEMORY) 0x0>,
> +          <0x00 0x61000000 0x00 0x1f000000 (PMA_RWXA | PMA_NONCOHERENT_MEMORY | PMR_ALIAS(3)) 0x0>,
> +          <0x00 0x80000000 0x08 0x00000000 (PMA_RWXA | PMA_NONCOHERENT_MEMORY) 0x0>,
> +          <0x10 0x00000000 0x08 0x00000000 (PMA_RWX | PMA_NONCACHEABLE_MEMORY | PMR_ALIAS(5)) 0x0>,
> +          <0x20 0x00000000 0x10 0x00000000 (PMA_RWX | PMA_NONCACHEABLE_MEMORY) 0x0>,
> +          <0x30 0x00000000 0x10 0x00000000 (PMA_RWXA | PMA_NONCOHERENT_MEMORY | PMR_ALIAS(7)) 0x0>;
> +    };
> +
> +...
> diff --git a/include/dt-bindings/riscv/physical-memory.h b/include/dt-bindings/riscv/physical-memory.h
> new file mode 100644
> index 000000000000..d6ed8015c535
> --- /dev/null
> +++ b/include/dt-bindings/riscv/physical-memory.h
> @@ -0,0 +1,45 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +
> +#ifndef _DT_BINDINGS_RISCV_PHYSICAL_MEMORY_H
> +#define _DT_BINDINGS_RISCV_PHYSICAL_MEMORY_H
> +
> +#define PMA_READ			(1 << 0)
> +#define PMA_WRITE			(1 << 1)
> +#define PMA_EXECUTE			(1 << 2)
> +#define PMA_AMO_MASK			(3 << 4)
> +#define PMA_AMO_NONE			(0 << 4)
> +#define PMA_AMO_SWAP			(1 << 4)
> +#define PMA_AMO_LOGICAL			(2 << 4)
> +#define PMA_AMO_ARITHMETIC		(3 << 4)
> +#define PMA_RSRV_MASK			(3 << 6)
> +#define PMA_RSRV_NONE			(0 << 6)
> +#define PMA_RSRV_NON_EVENTUAL		(1 << 6)
> +#define PMA_RSRV_EVENTUAL		(2 << 6)
> +
> +#define PMA_RW				(PMA_READ | PMA_WRITE)
> +#define PMA_RWA				(PMA_RW | PMA_AMO_ARITHMETIC | PMA_RSRV_EVENTUAL)
> +#define PMA_RWX				(PMA_RW | PMA_EXECUTE)
> +#define PMA_RWXA			(PMA_RWA | PMA_EXECUTE)
> +
> +#define PMA_ORDER_MASK			(3 << 8)
> +#define PMA_ORDER_IO_RELAXED		(0 << 8)
> +#define PMA_ORDER_IO_STRONG		(1 << 8)
> +#define PMA_ORDER_MEMORY		(2 << 8)
> +#define PMA_READ_IDEMPOTENT		(1 << 10)
> +#define PMA_WRITE_IDEMPOTENT		(1 << 11)
> +#define PMA_CACHEABLE			(1 << 12)
> +#define PMA_COHERENT			(1 << 13)
> +
> +#define PMA_UNSAFE			(1 << 15)
> +
> +#define PMA_IO				(PMA_ORDER_IO_RELAXED)
> +#define PMA_NONCACHEABLE_MEMORY		(PMA_ORDER_MEMORY | PMA_READ_IDEMPOTENT | \
> +						PMA_WRITE_IDEMPOTENT)
> +#define PMA_NONCOHERENT_MEMORY		(PMA_NONCACHEABLE_MEMORY | PMA_CACHEABLE)
> +#define PMA_NORMAL_MEMORY		(PMA_NONCOHERENT_MEMORY | PMA_COHERENT)
> +
> +#define PMR_ALIAS_MASK			(0x7f << 24)
> +#define PMR_IS_ALIAS			(0x80 << 24)
> +#define PMR_ALIAS(n)			(PMR_IS_ALIAS | ((n) << 24))
> +
> +#endif /* _DT_BINDINGS_RISCV_PHYSICAL_MEMORY_H */
> -- 
> 2.47.2
> 


  reply	other threads:[~2025-12-04 15:12 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-13  1:45 [PATCH v3 00/22] riscv: Memory type control for platforms with physical memory aliases Samuel Holland
2025-11-13  1:45 ` [PATCH v3 01/22] mm/ptdump: replace READ_ONCE() with standard page table accessors Samuel Holland
2025-11-13  1:45 ` [PATCH v3 02/22] mm: " Samuel Holland
2025-11-13  4:05   ` Dev Jain
2025-11-13  1:45 ` [PATCH v3 03/22] mm/dirty: replace READ_ONCE() with pudp_get() Samuel Holland
2025-11-13  1:45 ` [PATCH v3 04/22] perf/events: replace READ_ONCE() with standard page table accessors Samuel Holland
2025-11-13 19:10   ` David Hildenbrand (Red Hat)
2025-11-13  1:45 ` [PATCH v3 05/22] mm: Move the fallback definitions of pXXp_get() Samuel Holland
2025-11-13 19:11   ` David Hildenbrand (Red Hat)
2025-11-13  1:45 ` [PATCH v3 06/22] mm: Always use page table accessor functions Samuel Holland
2025-11-13  4:53   ` kernel test robot
2025-11-13  5:46   ` kernel test robot
2025-11-26 11:08   ` Christophe Leroy (CS GROUP)
2025-11-26 11:09   ` Ryan Roberts
2025-11-26 12:16     ` David Hildenbrand (Red Hat)
2025-11-26 12:19       ` David Hildenbrand (Red Hat)
2025-11-26 12:27         ` Lorenzo Stoakes
2025-11-26 12:35           ` David Hildenbrand (Red Hat)
2025-11-26 13:03             ` Ryan Roberts
2025-11-26 13:47               ` Wei Yang
2025-11-26 14:22                 ` Ryan Roberts
2025-11-26 14:37                   ` Lorenzo Stoakes
2025-11-26 14:53                     ` David Hildenbrand (Red Hat)
2025-11-26 14:46                   ` David Hildenbrand (Red Hat)
2025-11-26 14:52                     ` Lorenzo Stoakes
2025-11-26 14:56                       ` David Hildenbrand (Red Hat)
2025-11-26 15:08                         ` Lorenzo Stoakes
2025-11-26 15:12                           ` David Hildenbrand (Red Hat)
2025-11-26 16:07                             ` Ryan Roberts
2025-11-26 16:34                               ` Ryan Roberts
2025-11-26 20:31                                 ` David Hildenbrand (Red Hat)
2025-11-27  7:14                                   ` David Hildenbrand (Red Hat)
2025-11-27  7:31                                     ` David Hildenbrand (Red Hat)
2025-11-27 15:32                                       ` Ryan Roberts
2025-11-27 19:39                                 ` Christophe Leroy (CS GROUP)
2025-11-27 19:44                                 ` Christophe Leroy (CS GROUP)
2025-11-27  8:26                   ` Christophe Leroy (CS GROUP)
2025-11-27  8:35                     ` David Hildenbrand (Red Hat)
2025-11-13  1:45 ` [PATCH v3 07/22] checkpatch: Warn on page table access without accessors Samuel Holland
2025-11-13  2:21   ` Joe Perches
2025-11-13  2:36     ` Samuel Holland
2025-11-13 19:17       ` David Hildenbrand (Red Hat)
2025-11-13  1:45 ` [PATCH v3 08/22] mm: Allow page table accessors to be non-idempotent Samuel Holland
2025-11-13  7:19   ` kernel test robot
2025-11-27 16:57   ` Ryan Roberts
2025-11-27 17:47     ` David Hildenbrand (Red Hat)
2025-11-13  1:45 ` [PATCH v3 09/22] riscv: hibernate: Replace open-coded pXXp_get() Samuel Holland
2025-11-13  1:45 ` [PATCH v3 10/22] riscv: mm: Always use page table accessor functions Samuel Holland
2025-11-13  1:45 ` [PATCH v3 11/22] riscv: mm: Simplify set_p4d() and set_pgd() Samuel Holland
2025-11-13  1:45 ` [PATCH v3 12/22] riscv: mm: Deduplicate _PAGE_CHG_MASK definition Samuel Holland
2025-11-13  1:45 ` [PATCH v3 13/22] riscv: ptdump: Only show N and MT bits when enabled in the kernel Samuel Holland
2025-11-13  1:45 ` [PATCH v3 14/22] riscv: mm: Fix up memory types when writing page tables Samuel Holland
2025-11-13  1:45 ` [PATCH v3 15/22] riscv: mm: Expose all page table bits to assembly code Samuel Holland
2025-11-13  1:45 ` [PATCH v3 16/22] riscv: alternative: Add an ALTERNATIVE_3 macro Samuel Holland
2025-11-13  1:45 ` [PATCH v3 17/22] riscv: alternative: Allow calls with alternate link registers Samuel Holland
2025-11-13  1:45 ` [PATCH v3 18/22] riscv: Fix logic for selecting DMA_DIRECT_REMAP Samuel Holland
2025-11-13  1:45 ` [PATCH v3 19/22] dt-bindings: riscv: Describe physical memory regions Samuel Holland
2025-12-04 15:12   ` Rob Herring [this message]
2025-11-13  1:45 ` [PATCH v3 20/22] riscv: mm: Use physical memory aliases to apply PMAs Samuel Holland
2025-11-13  1:45 ` [PATCH v3 21/22] riscv: dts: starfive: jh7100: Use physical memory ranges for DMA Samuel Holland
2025-11-13  1:45 ` [PATCH v3 22/22] riscv: dts: eswin: eic7700: " Samuel Holland
2025-11-13 19:13 ` [PATCH v3 00/22] riscv: Memory type control for platforms with physical memory aliases David Hildenbrand (Red Hat)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251204151232.GA1394051-robh@kernel.org \
    --to=robh@kernel.org \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex@ghiti.fr \
    --cc=conor@kernel.org \
    --cc=david@redhat.com \
    --cc=devicetree@vger.kernel.org \
    --cc=kernel@esmil.dk \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mhocko@suse.com \
    --cc=palmer@dabbelt.com \
    --cc=pjw@kernel.org \
    --cc=rppt@kernel.org \
    --cc=samuel.holland@sifive.com \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox