[PATCH 00/11] riscv: Memory type control for platforms with physical memory aliases

Samuel Holland posted 11 patches 1 year, 3 months ago
There is a newer version of this series
.../bindings/riscv/physical-memory.yaml       | 101 ++++++++++
arch/riscv/Kconfig                            |   3 +
arch/riscv/Kconfig.errata                     |  20 +-
.../boot/dts/starfive/jh7100-common.dtsi      |  30 +--
arch/riscv/include/asm/alternative-macros.h   |  45 ++++-
arch/riscv/include/asm/errata_list.h          |  45 -----
arch/riscv/include/asm/hwcap.h                |   1 +
arch/riscv/include/asm/pgtable-32.h           |  19 +-
arch/riscv/include/asm/pgtable-64.h           | 178 ++++++++++--------
arch/riscv/include/asm/pgtable-bits.h         |  42 ++++-
arch/riscv/include/asm/pgtable.h              |  55 +++---
arch/riscv/kernel/alternative.c               |   4 +-
arch/riscv/kernel/cpufeature.c                |   6 +
arch/riscv/kernel/setup.c                     |   1 +
arch/riscv/mm/Makefile                        |   1 +
arch/riscv/mm/init.c                          |   8 +-
arch/riscv/mm/kasan_init.c                    |   8 +-
arch/riscv/mm/memory-alias.S                  | 101 ++++++++++
arch/riscv/mm/pageattr.c                      |  17 +-
arch/riscv/mm/pgtable.c                       |  91 +++++++++
arch/riscv/mm/ptdump.c                        |  19 +-
include/dt-bindings/riscv/physical-memory.h   |  44 +++++
22 files changed, 596 insertions(+), 243 deletions(-)
create mode 100644 Documentation/devicetree/bindings/riscv/physical-memory.yaml
create mode 100644 arch/riscv/mm/memory-alias.S
create mode 100644 include/dt-bindings/riscv/physical-memory.h
[PATCH 00/11] riscv: Memory type control for platforms with physical memory aliases
Posted by Samuel Holland 1 year, 3 months ago
On some RISC-V platforms, including StarFive JH7100 and ESWIN EIC7700,
RAM is mapped to multiple physical address ranges, with each alias
having a different set of statically-determined Physical Memory
Attributes (PMAs). Software selects the PMAs for a page by choosing 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.

 - Patch 1 adds a new binding to describe physical memory regions in
   the devicetree.
 - Patches 2-6 refactor existing memory type support to be modeled as
   variants on top of Svpbmt.
 - Patches 7-10 add logic to transform the PFN to use the desired alias
   when reading/writing page tables.
 - Patch 11 enables this new method of memory type control on JH7100.

I have boot-tested this series on platforms with each of the 4 ways to
select a memory type: SiFive FU740 (none), QEMU (Svpbmt), Allwinner D1
(XTheadMae), and ESWIN EIC7700 (aliases).


Samuel Holland (11):
  dt-bindings: riscv: Describe physical memory regions
  riscv: mm: Increment PFN in place when splitting mappings
  riscv: mm: Deduplicate pgtable address conversion functions
  riscv: mm: Deduplicate _PAGE_CHG_MASK definition
  riscv: ptdump: Only show N and MT bits when enabled in the kernel
  riscv: mm: Fix up memory types when writing page tables
  riscv: mm: Expose all page table bits to assembly code
  riscv: alternative: Add an ALTERNATIVE_3 macro
  riscv: alternative: Allow calls with alternate link registers
  riscv: mm: Use physical memory aliases to apply PMAs
  riscv: dts: starfive: jh7100: Use physical memory ranges for DMA

 .../bindings/riscv/physical-memory.yaml       | 101 ++++++++++
 arch/riscv/Kconfig                            |   3 +
 arch/riscv/Kconfig.errata                     |  20 +-
 .../boot/dts/starfive/jh7100-common.dtsi      |  30 +--
 arch/riscv/include/asm/alternative-macros.h   |  45 ++++-
 arch/riscv/include/asm/errata_list.h          |  45 -----
 arch/riscv/include/asm/hwcap.h                |   1 +
 arch/riscv/include/asm/pgtable-32.h           |  19 +-
 arch/riscv/include/asm/pgtable-64.h           | 178 ++++++++++--------
 arch/riscv/include/asm/pgtable-bits.h         |  42 ++++-
 arch/riscv/include/asm/pgtable.h              |  55 +++---
 arch/riscv/kernel/alternative.c               |   4 +-
 arch/riscv/kernel/cpufeature.c                |   6 +
 arch/riscv/kernel/setup.c                     |   1 +
 arch/riscv/mm/Makefile                        |   1 +
 arch/riscv/mm/init.c                          |   8 +-
 arch/riscv/mm/kasan_init.c                    |   8 +-
 arch/riscv/mm/memory-alias.S                  | 101 ++++++++++
 arch/riscv/mm/pageattr.c                      |  17 +-
 arch/riscv/mm/pgtable.c                       |  91 +++++++++
 arch/riscv/mm/ptdump.c                        |  19 +-
 include/dt-bindings/riscv/physical-memory.h   |  44 +++++
 22 files changed, 596 insertions(+), 243 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/riscv/physical-memory.yaml
 create mode 100644 arch/riscv/mm/memory-alias.S
 create mode 100644 include/dt-bindings/riscv/physical-memory.h

-- 
2.45.1
Re: [PATCH 00/11] riscv: Memory type control for platforms with physical memory aliases
Posted by Bo Gan 4 months, 2 weeks ago
On 11/1/24 17:07, Samuel Holland wrote:
> 
> On some RISC-V platforms, including StarFive JH7100 and ESWIN EIC7700,
> RAM is mapped to multiple physical address ranges, with each alias
> having a different set of statically-determined Physical Memory
> Attributes (PMAs). Software selects the PMAs for a page by choosing 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.
> 
>   - Patch 1 adds a new binding to describe physical memory regions in
>     the devicetree.
>   - Patches 2-6 refactor existing memory type support to be modeled as
>     variants on top of Svpbmt.
>   - Patches 7-10 add logic to transform the PFN to use the desired alias
>     when reading/writing page tables.
>   - Patch 11 enables this new method of memory type control on JH7100.
> 
> I have boot-tested this series on platforms with each of the 4 ways to
> select a memory type: SiFive FU740 (none), QEMU (Svpbmt), Allwinner D1
> (XTheadMae), and ESWIN EIC7700 (aliases).
> 

Hi Samuel,

Any update on this? I see ESWIN has started their EIC7700 upstreaming
effort, and it'll likely rely on this. Is there any follow up series?
BTW, Icenowy's working on upstreaming the Verisilicon DC8200 driver.
His work also depend on this patchset in order to test on JH7110/EIC7700

Thanks!