[PATCH V4 0/2] riscv: add RISC-V Svpbmt Standard Extension supports

[PATCH V4 0/2] riscv: add RISC-V Svpbmt Standard Extension supports

[wefu]

From: Fu Wei <wefu@redhat.com>

This patch follows the  RISC-V standard Svpbmt extension in 
privilege spec to solve the non-coherent SOC DMA synchronization
issues.

The svpbmt PTE format:
| 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
  N     MT     RSW    D   A   G   U   X   W   R   V
        ^

Of the Reserved bits [63:54] in a leaf PTE, the bits [62:61] are used as
the MT (aka MemType) field. This field specifies one of three memory types
as shown in the following table：
MemType     RISC-V Description
----------  ------------------------------------------------
00 - PMA    Normal Cacheable, No change to implied PMA memory type
01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
11 - Rsvd   Reserved for future standard use

The standard protection_map[] needn't be modified because the "PMA"
type keeps the highest bits zero.
And the whole modification is limited in the arch/riscv/* and using
a global variable(__svpbmt) as _PAGE_MASK/IO/NOCACHE for pgprot_noncached
(&writecombine) in pgtable.h. We also add _PAGE_CHG_MASK to filter
PFN than before.

Enable it in devicetree - (Add "riscv,svpbmt" in the mmu of cpu node)
 - mmu:
     riscv,svpmbt

Wei Fu (2):
  dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt
  riscv: add RISC-V Svpbmt extension supports

 .../devicetree/bindings/riscv/cpus.yaml       | 10 +++++
 arch/riscv/include/asm/fixmap.h               |  2 +-
 arch/riscv/include/asm/pgtable-64.h           | 21 ++++++++--
 arch/riscv/include/asm/pgtable-bits.h         | 39 ++++++++++++++++++-
 arch/riscv/include/asm/pgtable.h              | 39 ++++++++++++++-----
 arch/riscv/kernel/cpufeature.c                | 35 +++++++++++++++++
 arch/riscv/mm/init.c                          |  5 +++
 7 files changed, 136 insertions(+), 15 deletions(-)

-- 
2.25.4

[PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt

[wefu]

From: Wei Fu <wefu@redhat.com> 

Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt"
in the DT mmu node. Update dt-bindings related property here.

Signed-off-by: Wei Fu <wefu@redhat.com>
Co-developed-by: Guo Ren <guoren@kernel.org>
Signed-off-by: Guo Ren <guoren@kernel.org>
Cc: Anup Patel <anup@brainfault.org>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Rob Herring <robh+dt@kernel.org>
---
 Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
index aa5fb64d57eb..9ff9cbdd8a85 100644
--- a/Documentation/devicetree/bindings/riscv/cpus.yaml
+++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
@@ -63,6 +63,16 @@ properties:
       - riscv,sv48
       - riscv,none
 
+  mmu:
+    description:
+      Describes the CPU's MMU Standard Extensions support.
+      These values originate from the RISC-V Privileged
+      Specification document, available from
+      https://riscv.org/specifications/
+    $ref: '/schemas/types.yaml#/definitions/string'
+    enum:
+      - riscv,svpmbt
+
   riscv,isa:
     description:
       Identifies the specific RISC-V instruction set architecture
-- 
2.25.4

[PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports

[wefu]

From: Wei Fu <wefu@redhat.com>

This patch follows the standard pure RISC-V Svpbmt extension in
privilege spec to solve the non-coherent SOC dma synchronization
issues.

Here is the svpbmt PTE format:
| 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
  N     MT     RSW    D   A   G   U   X   W   R   V
        ^

Of the Reserved bits [63:54] in a leaf PTE, the high bit is already
allocated (as the N bit), so bits [62:61] are used as the MT (aka
MemType) field. This field specifies one of three memory types that
are close equivalents (or equivalent in effect) to the three main x86
and ARMv8 memory types - as shown in the following table.

RISC-V
Encoding &
MemType     RISC-V Description
----------  ------------------------------------------------
00 - PMA    Normal Cacheable, No change to implied PMA memory type
01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
11 - Rsvd   Reserved for future standard use

The standard protection_map[] needn't be modified because the "PMA"
type keeps the highest bits zero. And the whole modification is
limited in the arch/riscv/* and using a global variable
(__svpbmt) as _PAGE_MASK/IO/NOCACHE for pgprot_noncached
(&writecombine) in pgtable.h. We also add _PAGE_CHG_MASK to filter
PFN than before.

Enable it in devicetree - (Add "riscv,svpbmt" in the mmu of cpu node)
 - mmu:
     riscv,svpmbt

Signed-off-by: Wei Fu <wefu@redhat.com>
Co-developed-by: Liu Shaohua <liush@allwinnertech.com>
Signed-off-by: Liu Shaohua <liush@allwinnertech.com>
Co-developed-by: Guo Ren <guoren@kernel.org>
Signed-off-by: Guo Ren <guoren@kernel.org>
Cc: Palmer Dabbelt <palmerdabbelt@google.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Anup Patel <anup.patel@wdc.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Atish Patra <atish.patra@wdc.com>
Cc: Drew Fustini <drew@beagleboard.org>
Cc: Wei Fu <wefu@redhat.com>
Cc: Wei Wu <lazyparser@gmail.com>
Cc: Chen-Yu Tsai <wens@csie.org>
Cc: Maxime Ripard <maxime@cerno.tech>
Cc: Daniel Lustig <dlustig@nvidia.com>
Cc: Greg Favor <gfavor@ventanamicro.com>
Cc: Andrea Mondelli <andrea.mondelli@huawei.com>
Cc: Jonathan Behrens <behrensj@mit.edu>
Cc: Xinhaoqu (Freddie) <xinhaoqu@huawei.com>
Cc: Bill Huffman <huffman@cadence.com>
Cc: Nick Kossifidis <mick@ics.forth.gr>
Cc: Allen Baum <allen.baum@esperantotech.com>
Cc: Josh Scheid <jscheid@ventanamicro.com>
Cc: Richard Trauben <rtrauben@gmail.com>
---
 arch/riscv/include/asm/fixmap.h       |  2 +-
 arch/riscv/include/asm/pgtable-64.h   | 21 ++++++++++++---
 arch/riscv/include/asm/pgtable-bits.h | 39 +++++++++++++++++++++++++--
 arch/riscv/include/asm/pgtable.h      | 39 ++++++++++++++++++++-------
 arch/riscv/kernel/cpufeature.c        | 35 ++++++++++++++++++++++++
 arch/riscv/mm/init.c                  |  5 ++++
 6 files changed, 126 insertions(+), 15 deletions(-)

diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h
index 54cbf07fb4e9..5acd99d08e74 100644
--- a/arch/riscv/include/asm/fixmap.h
+++ b/arch/riscv/include/asm/fixmap.h
@@ -43,7 +43,7 @@ enum fixed_addresses {
 	__end_of_fixed_addresses
 };
 
-#define FIXMAP_PAGE_IO		PAGE_KERNEL
+#define FIXMAP_PAGE_IO		PAGE_IOREMAP
 
 #define __early_set_fixmap	__set_fixmap
 
diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h
index 228261aa9628..16d251282b1d 100644
--- a/arch/riscv/include/asm/pgtable-64.h
+++ b/arch/riscv/include/asm/pgtable-64.h
@@ -59,14 +59,29 @@ static inline void pud_clear(pud_t *pudp)
 	set_pud(pudp, __pud(0));
 }
 
+static inline unsigned long _chg_of_pmd(pmd_t pmd)
+{
+	return (pmd_val(pmd) & _PAGE_CHG_MASK);
+}
+
+static inline unsigned long _chg_of_pud(pud_t pud)
+{
+	return (pud_val(pud) & _PAGE_CHG_MASK);
+}
+
+static inline unsigned long _chg_of_pte(pte_t pte)
+{
+	return (pte_val(pte) & _PAGE_CHG_MASK);
+}
+
 static inline pmd_t *pud_pgtable(pud_t pud)
 {
-	return (pmd_t *)pfn_to_virt(pud_val(pud) >> _PAGE_PFN_SHIFT);
+	return (pmd_t *)pfn_to_virt(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT);
 }
 
 static inline struct page *pud_page(pud_t pud)
 {
-	return pfn_to_page(pud_val(pud) >> _PAGE_PFN_SHIFT);
+	return pfn_to_page(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT);
 }
 
 static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot)
@@ -76,7 +91,7 @@ static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot)
 
 static inline unsigned long _pmd_pfn(pmd_t pmd)
 {
-	return pmd_val(pmd) >> _PAGE_PFN_SHIFT;
+	return _chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT;
 }
 
 #define mk_pmd(page, prot)    pfn_pmd(page_to_pfn(page), prot)
diff --git a/arch/riscv/include/asm/pgtable-bits.h b/arch/riscv/include/asm/pgtable-bits.h
index 2ee413912926..e5b0fce4ddc5 100644
--- a/arch/riscv/include/asm/pgtable-bits.h
+++ b/arch/riscv/include/asm/pgtable-bits.h
@@ -7,7 +7,7 @@
 #define _ASM_RISCV_PGTABLE_BITS_H
 
 /*
- * PTE format:
+ * rv32 PTE format:
  * | XLEN-1  10 | 9             8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
  *       PFN      reserved for SW   D   A   G   U   X   W   R   V
  */
@@ -24,6 +24,40 @@
 #define _PAGE_DIRTY     (1 << 7)    /* Set by hardware on any write */
 #define _PAGE_SOFT      (1 << 8)    /* Reserved for software */
 
+#if !defined(__ASSEMBLY__) && defined(CONFIG_64BIT)
+/*
+ * rv64 PTE format:
+ * | 63 | 62 61 | 60 54 | 53  10 | 9             8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
+ *   N      MT     RSV    PFN      reserved for SW   D   A   G   U   X   W   R   V
+ * [62:61] Memory Type definitions:
+ *  00 - PMA    Normal Cacheable, No change to implied PMA memory type
+ *  01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
+ *  10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
+ *  11 - Rsvd   Reserved for future standard use
+ */
+#define _SVPBMT_PMA		0UL
+#define _SVPBMT_NC		(1UL << 61)
+#define _SVPBMT_IO		(1UL << 62)
+#define _SVPBMT_MASK		(_SVPBMT_NC | _SVPBMT_IO)
+
+extern struct __svpbmt_struct {
+	unsigned long mask;
+	unsigned long pma;
+	unsigned long nocache;
+	unsigned long io;
+} __svpbmt __cacheline_aligned;
+
+#define _PAGE_MASK		__svpbmt.mask
+#define _PAGE_PMA		__svpbmt.pma
+#define _PAGE_NOCACHE		__svpbmt.nocache
+#define _PAGE_IO		__svpbmt.io
+#else
+#define _PAGE_MASK		0
+#define _PAGE_PMA		0
+#define _PAGE_NOCACHE		0
+#define _PAGE_IO		0
+#endif /* !__ASSEMBLY__ && CONFIG_64BIT */
+
 #define _PAGE_SPECIAL   _PAGE_SOFT
 #define _PAGE_TABLE     _PAGE_PRESENT
 
@@ -38,7 +72,8 @@
 /* Set of bits to preserve across pte_modify() */
 #define _PAGE_CHG_MASK  (~(unsigned long)(_PAGE_PRESENT | _PAGE_READ |	\
 					  _PAGE_WRITE | _PAGE_EXEC |	\
-					  _PAGE_USER | _PAGE_GLOBAL))
+					  _PAGE_USER | _PAGE_GLOBAL |	\
+					  _PAGE_MASK))
 /*
  * when all of R/W/X are zero, the PTE is a pointer to the next level
  * of the page table; otherwise, it is a leaf PTE.
diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
index bf204e7c1f74..0f7a6541015f 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -138,7 +138,8 @@
 				| _PAGE_PRESENT \
 				| _PAGE_ACCESSED \
 				| _PAGE_DIRTY \
-				| _PAGE_GLOBAL)
+				| _PAGE_GLOBAL \
+				| _PAGE_PMA)
 
 #define PAGE_KERNEL		__pgprot(_PAGE_KERNEL)
 #define PAGE_KERNEL_READ	__pgprot(_PAGE_KERNEL & ~_PAGE_WRITE)
@@ -148,11 +149,9 @@
 
 #define PAGE_TABLE		__pgprot(_PAGE_TABLE)
 
-/*
- * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't
- * change the properties of memory regions.
- */
-#define _PAGE_IOREMAP _PAGE_KERNEL
+#define _PAGE_IOREMAP	((_PAGE_KERNEL & ~_PAGE_MASK) | _PAGE_IO)
+
+#define PAGE_IOREMAP		__pgprot(_PAGE_IOREMAP)
 
 extern pgd_t swapper_pg_dir[];
 
@@ -232,12 +231,12 @@ static inline unsigned long _pgd_pfn(pgd_t pgd)
 
 static inline struct page *pmd_page(pmd_t pmd)
 {
-	return pfn_to_page(pmd_val(pmd) >> _PAGE_PFN_SHIFT);
+	return pfn_to_page(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT);
 }
 
 static inline unsigned long pmd_page_vaddr(pmd_t pmd)
 {
-	return (unsigned long)pfn_to_virt(pmd_val(pmd) >> _PAGE_PFN_SHIFT);
+	return (unsigned long)pfn_to_virt(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT);
 }
 
 static inline pte_t pmd_pte(pmd_t pmd)
@@ -253,7 +252,7 @@ static inline pte_t pud_pte(pud_t pud)
 /* Yields the page frame number (PFN) of a page table entry */
 static inline unsigned long pte_pfn(pte_t pte)
 {
-	return (pte_val(pte) >> _PAGE_PFN_SHIFT);
+	return (_chg_of_pte(pte) >> _PAGE_PFN_SHIFT);
 }
 
 #define pte_page(x)     pfn_to_page(pte_pfn(x))
@@ -492,6 +491,28 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma,
 	return ptep_test_and_clear_young(vma, address, ptep);
 }
 
+#define pgprot_noncached pgprot_noncached
+static inline pgprot_t pgprot_noncached(pgprot_t _prot)
+{
+	unsigned long prot = pgprot_val(_prot);
+
+	prot &= ~_PAGE_MASK;
+	prot |= _PAGE_IO;
+
+	return __pgprot(prot);
+}
+
+#define pgprot_writecombine pgprot_writecombine
+static inline pgprot_t pgprot_writecombine(pgprot_t _prot)
+{
+	unsigned long prot = pgprot_val(_prot);
+
+	prot &= ~_PAGE_MASK;
+	prot |= _PAGE_NOCACHE;
+
+	return __pgprot(prot);
+}
+
 /*
  * THP functions
  */
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index d959d207a40d..fa7480cb8b87 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -8,6 +8,7 @@
 
 #include <linux/bitmap.h>
 #include <linux/of.h>
+#include <linux/pgtable.h>
 #include <asm/processor.h>
 #include <asm/hwcap.h>
 #include <asm/smp.h>
@@ -59,6 +60,38 @@ bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit)
 }
 EXPORT_SYMBOL_GPL(__riscv_isa_extension_available);
 
+static void __init mmu_supports_svpbmt(void)
+{
+#if defined(CONFIG_MMU) && defined(CONFIG_64BIT)
+	struct device_node *node;
+	const char *str;
+
+	for_each_of_cpu_node(node) {
+		if (of_property_read_string(node, "mmu-type", &str))
+			continue;
+
+		if (!strncmp(str + 6, "none", 4))
+			continue;
+
+		if (of_property_read_string(node, "mmu", &str))
+			continue;
+
+		if (strncmp(str + 6, "svpmbt", 6))
+			continue;
+	}
+
+	__svpbmt.pma		= _SVPBMT_PMA;
+	__svpbmt.nocache	= _SVPBMT_NC;
+	__svpbmt.io		= _SVPBMT_IO;
+	__svpbmt.mask		= _SVPBMT_MASK;
+#endif
+}
+
+static void __init mmu_supports(void)
+{
+	mmu_supports_svpbmt();
+}
+
 void __init riscv_fill_hwcap(void)
 {
 	struct device_node *node;
@@ -67,6 +100,8 @@ void __init riscv_fill_hwcap(void)
 	size_t i, j, isa_len;
 	static unsigned long isa2hwcap[256] = {0};
 
+	mmu_supports();
+
 	isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I;
 	isa2hwcap['m'] = isa2hwcap['M'] = COMPAT_HWCAP_ISA_M;
 	isa2hwcap['a'] = isa2hwcap['A'] = COMPAT_HWCAP_ISA_A;
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index 24b2b8044602..e4e658165ee1 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -854,3 +854,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
 	return vmemmap_populate_basepages(start, end, node, NULL);
 }
 #endif
+
+#if defined(CONFIG_64BIT)
+struct __svpbmt_struct __svpbmt __ro_after_init;
+EXPORT_SYMBOL(__svpbmt);
+#endif
-- 
2.25.4

Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt

[Heinrich Schuchardt]

On 11/29/21 02:40, wefu@redhat.com wrote:
> From: Wei Fu <wefu@redhat.com>
> 
> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt"
> in the DT mmu node. Update dt-bindings related property here.
> 
> Signed-off-by: Wei Fu <wefu@redhat.com>
> Co-developed-by: Guo Ren <guoren@kernel.org>
> Signed-off-by: Guo Ren <guoren@kernel.org>
> Cc: Anup Patel <anup@brainfault.org>
> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> ---
>   Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++
>   1 file changed, 10 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> index aa5fb64d57eb..9ff9cbdd8a85 100644
> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> @@ -63,6 +63,16 @@ properties:
>         - riscv,sv48
>         - riscv,none
>   
> +  mmu:

Shouldn't we keep the items be in alphabetic order, i.e. mmu before 
mmu-type?

> +    description:
> +      Describes the CPU's MMU Standard Extensions support.
> +      These values originate from the RISC-V Privileged
> +      Specification document, available from
> +      https://riscv.org/specifications/
> +    $ref: '/schemas/types.yaml#/definitions/string'
> +    enum:
> +      - riscv,svpmbt

The privileged specification has multiple MMU related extensions: 
Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum?

Best regards

Heinrich

> +
>     riscv,isa:
>       description:
>         Identifies the specific RISC-V instruction set architecture
> 

Re: [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports

[Alexandre Ghiti]

On Mon, Nov 29, 2021 at 2:42 AM <wefu@redhat.com> wrote:
>
> From: Wei Fu <wefu@redhat.com>
>
> This patch follows the standard pure RISC-V Svpbmt extension in
> privilege spec to solve the non-coherent SOC dma synchronization
> issues.
>
> Here is the svpbmt PTE format:
> | 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
>   N     MT     RSW    D   A   G   U   X   W   R   V
>         ^
>
> Of the Reserved bits [63:54] in a leaf PTE, the high bit is already
> allocated (as the N bit), so bits [62:61] are used as the MT (aka
> MemType) field. This field specifies one of three memory types that
> are close equivalents (or equivalent in effect) to the three main x86
> and ARMv8 memory types - as shown in the following table.
>
> RISC-V
> Encoding &
> MemType     RISC-V Description
> ----------  ------------------------------------------------
> 00 - PMA    Normal Cacheable, No change to implied PMA memory type
> 01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
> 10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
> 11 - Rsvd   Reserved for future standard use
>
> The standard protection_map[] needn't be modified because the "PMA"
> type keeps the highest bits zero. And the whole modification is
> limited in the arch/riscv/* and using a global variable
> (__svpbmt) as _PAGE_MASK/IO/NOCACHE for pgprot_noncached
> (&writecombine) in pgtable.h. We also add _PAGE_CHG_MASK to filter
> PFN than before.
>
> Enable it in devicetree - (Add "riscv,svpbmt" in the mmu of cpu node)
>  - mmu:
>      riscv,svpmbt
>
> Signed-off-by: Wei Fu <wefu@redhat.com>
> Co-developed-by: Liu Shaohua <liush@allwinnertech.com>
> Signed-off-by: Liu Shaohua <liush@allwinnertech.com>
> Co-developed-by: Guo Ren <guoren@kernel.org>
> Signed-off-by: Guo Ren <guoren@kernel.org>
> Cc: Palmer Dabbelt <palmerdabbelt@google.com>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Anup Patel <anup.patel@wdc.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Atish Patra <atish.patra@wdc.com>
> Cc: Drew Fustini <drew@beagleboard.org>
> Cc: Wei Fu <wefu@redhat.com>
> Cc: Wei Wu <lazyparser@gmail.com>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Cc: Maxime Ripard <maxime@cerno.tech>
> Cc: Daniel Lustig <dlustig@nvidia.com>
> Cc: Greg Favor <gfavor@ventanamicro.com>
> Cc: Andrea Mondelli <andrea.mondelli@huawei.com>
> Cc: Jonathan Behrens <behrensj@mit.edu>
> Cc: Xinhaoqu (Freddie) <xinhaoqu@huawei.com>
> Cc: Bill Huffman <huffman@cadence.com>
> Cc: Nick Kossifidis <mick@ics.forth.gr>
> Cc: Allen Baum <allen.baum@esperantotech.com>
> Cc: Josh Scheid <jscheid@ventanamicro.com>
> Cc: Richard Trauben <rtrauben@gmail.com>
> ---
>  arch/riscv/include/asm/fixmap.h       |  2 +-
>  arch/riscv/include/asm/pgtable-64.h   | 21 ++++++++++++---
>  arch/riscv/include/asm/pgtable-bits.h | 39 +++++++++++++++++++++++++--
>  arch/riscv/include/asm/pgtable.h      | 39 ++++++++++++++++++++-------
>  arch/riscv/kernel/cpufeature.c        | 35 ++++++++++++++++++++++++
>  arch/riscv/mm/init.c                  |  5 ++++
>  6 files changed, 126 insertions(+), 15 deletions(-)
>
> diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h
> index 54cbf07fb4e9..5acd99d08e74 100644
> --- a/arch/riscv/include/asm/fixmap.h
> +++ b/arch/riscv/include/asm/fixmap.h
> @@ -43,7 +43,7 @@ enum fixed_addresses {
>         __end_of_fixed_addresses
>  };
>
> -#define FIXMAP_PAGE_IO         PAGE_KERNEL
> +#define FIXMAP_PAGE_IO         PAGE_IOREMAP
>
>  #define __early_set_fixmap     __set_fixmap
>
> diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h
> index 228261aa9628..16d251282b1d 100644
> --- a/arch/riscv/include/asm/pgtable-64.h
> +++ b/arch/riscv/include/asm/pgtable-64.h
> @@ -59,14 +59,29 @@ static inline void pud_clear(pud_t *pudp)
>         set_pud(pudp, __pud(0));
>  }
>
> +static inline unsigned long _chg_of_pmd(pmd_t pmd)
> +{
> +       return (pmd_val(pmd) & _PAGE_CHG_MASK);
> +}
> +
> +static inline unsigned long _chg_of_pud(pud_t pud)
> +{
> +       return (pud_val(pud) & _PAGE_CHG_MASK);
> +}
> +
> +static inline unsigned long _chg_of_pte(pte_t pte)
> +{
> +       return (pte_val(pte) & _PAGE_CHG_MASK);
> +}

Those functions are used to extract the pfn from a page table entry,
IMO it would be clearer if those functions would look like that:

static inline unsigned long pmd_to_pfn(pmd_t pmd)
{
    return (pmd_val(pmd) & _PAGE_CHG_MASK) >> _PAGE_PFN_SHIFT;
}

> +
>  static inline pmd_t *pud_pgtable(pud_t pud)
>  {
> -       return (pmd_t *)pfn_to_virt(pud_val(pud) >> _PAGE_PFN_SHIFT);
> +       return (pmd_t *)pfn_to_virt(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT);
>  }
>
>  static inline struct page *pud_page(pud_t pud)
>  {
> -       return pfn_to_page(pud_val(pud) >> _PAGE_PFN_SHIFT);
> +       return pfn_to_page(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT);
>  }
>
>  static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot)
> @@ -76,7 +91,7 @@ static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot)
>
>  static inline unsigned long _pmd_pfn(pmd_t pmd)
>  {
> -       return pmd_val(pmd) >> _PAGE_PFN_SHIFT;
> +       return _chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT;
>  }
>

Like this one actually, so if this exists for other levels, I would
suggest to modify those functions to directly mask the PMA bits and
use those in the whole code instead of manually extracting the pfn.

>  #define mk_pmd(page, prot)    pfn_pmd(page_to_pfn(page), prot)
> diff --git a/arch/riscv/include/asm/pgtable-bits.h b/arch/riscv/include/asm/pgtable-bits.h
> index 2ee413912926..e5b0fce4ddc5 100644
> --- a/arch/riscv/include/asm/pgtable-bits.h
> +++ b/arch/riscv/include/asm/pgtable-bits.h
> @@ -7,7 +7,7 @@
>  #define _ASM_RISCV_PGTABLE_BITS_H
>
>  /*
> - * PTE format:
> + * rv32 PTE format:
>   * | XLEN-1  10 | 9             8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
>   *       PFN      reserved for SW   D   A   G   U   X   W   R   V
>   */
> @@ -24,6 +24,40 @@
>  #define _PAGE_DIRTY     (1 << 7)    /* Set by hardware on any write */
>  #define _PAGE_SOFT      (1 << 8)    /* Reserved for software */
>
> +#if !defined(__ASSEMBLY__) && defined(CONFIG_64BIT)
> +/*
> + * rv64 PTE format:
> + * | 63 | 62 61 | 60 54 | 53  10 | 9             8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
> + *   N      MT     RSV    PFN      reserved for SW   D   A   G   U   X   W   R   V
> + * [62:61] Memory Type definitions:
> + *  00 - PMA    Normal Cacheable, No change to implied PMA memory type
> + *  01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
> + *  10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
> + *  11 - Rsvd   Reserved for future standard use
> + */
> +#define _SVPBMT_PMA            0UL
> +#define _SVPBMT_NC             (1UL << 61)
> +#define _SVPBMT_IO             (1UL << 62)
> +#define _SVPBMT_MASK           (_SVPBMT_NC | _SVPBMT_IO)
> +
> +extern struct __svpbmt_struct {
> +       unsigned long mask;
> +       unsigned long pma;
> +       unsigned long nocache;
> +       unsigned long io;
> +} __svpbmt __cacheline_aligned;
> +
> +#define _PAGE_MASK             __svpbmt.mask

To me, _PAGE_MASK means something else:
https://elixir.bootlin.com/linux/latest/source/arch/s390/include/asm/page.h#L16
Maybe something more explicit like _PAGE_SVPBMT_MASK?

> +#define _PAGE_PMA              __svpbmt.pma
> +#define _PAGE_NOCACHE          __svpbmt.nocache
> +#define _PAGE_IO               __svpbmt.io
> +#else
> +#define _PAGE_MASK             0
> +#define _PAGE_PMA              0
> +#define _PAGE_NOCACHE          0
> +#define _PAGE_IO               0
> +#endif /* !__ASSEMBLY__ && CONFIG_64BIT */
> +
>  #define _PAGE_SPECIAL   _PAGE_SOFT
>  #define _PAGE_TABLE     _PAGE_PRESENT
>
> @@ -38,7 +72,8 @@
>  /* Set of bits to preserve across pte_modify() */
>  #define _PAGE_CHG_MASK  (~(unsigned long)(_PAGE_PRESENT | _PAGE_READ | \
>                                           _PAGE_WRITE | _PAGE_EXEC |    \
> -                                         _PAGE_USER | _PAGE_GLOBAL))
> +                                         _PAGE_USER | _PAGE_GLOBAL |   \
> +                                         _PAGE_MASK))
>  /*
>   * when all of R/W/X are zero, the PTE is a pointer to the next level
>   * of the page table; otherwise, it is a leaf PTE.
> diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
> index bf204e7c1f74..0f7a6541015f 100644
> --- a/arch/riscv/include/asm/pgtable.h
> +++ b/arch/riscv/include/asm/pgtable.h
> @@ -138,7 +138,8 @@
>                                 | _PAGE_PRESENT \
>                                 | _PAGE_ACCESSED \
>                                 | _PAGE_DIRTY \
> -                               | _PAGE_GLOBAL)
> +                               | _PAGE_GLOBAL \
> +                               | _PAGE_PMA)
>
>  #define PAGE_KERNEL            __pgprot(_PAGE_KERNEL)
>  #define PAGE_KERNEL_READ       __pgprot(_PAGE_KERNEL & ~_PAGE_WRITE)
> @@ -148,11 +149,9 @@
>
>  #define PAGE_TABLE             __pgprot(_PAGE_TABLE)
>
> -/*
> - * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't
> - * change the properties of memory regions.
> - */
> -#define _PAGE_IOREMAP _PAGE_KERNEL
> +#define _PAGE_IOREMAP  ((_PAGE_KERNEL & ~_PAGE_MASK) | _PAGE_IO)
> +
> +#define PAGE_IOREMAP           __pgprot(_PAGE_IOREMAP)
>
>  extern pgd_t swapper_pg_dir[];
>
> @@ -232,12 +231,12 @@ static inline unsigned long _pgd_pfn(pgd_t pgd)
>
>  static inline struct page *pmd_page(pmd_t pmd)
>  {
> -       return pfn_to_page(pmd_val(pmd) >> _PAGE_PFN_SHIFT);
> +       return pfn_to_page(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT);
>  }
>
>  static inline unsigned long pmd_page_vaddr(pmd_t pmd)
>  {
> -       return (unsigned long)pfn_to_virt(pmd_val(pmd) >> _PAGE_PFN_SHIFT);
> +       return (unsigned long)pfn_to_virt(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT);
>  }
>
>  static inline pte_t pmd_pte(pmd_t pmd)
> @@ -253,7 +252,7 @@ static inline pte_t pud_pte(pud_t pud)
>  /* Yields the page frame number (PFN) of a page table entry */
>  static inline unsigned long pte_pfn(pte_t pte)
>  {
> -       return (pte_val(pte) >> _PAGE_PFN_SHIFT);
> +       return (_chg_of_pte(pte) >> _PAGE_PFN_SHIFT);
>  }
>
>  #define pte_page(x)     pfn_to_page(pte_pfn(x))
> @@ -492,6 +491,28 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma,
>         return ptep_test_and_clear_young(vma, address, ptep);
>  }
>
> +#define pgprot_noncached pgprot_noncached
> +static inline pgprot_t pgprot_noncached(pgprot_t _prot)
> +{
> +       unsigned long prot = pgprot_val(_prot);
> +
> +       prot &= ~_PAGE_MASK;
> +       prot |= _PAGE_IO;
> +
> +       return __pgprot(prot);
> +}
> +
> +#define pgprot_writecombine pgprot_writecombine
> +static inline pgprot_t pgprot_writecombine(pgprot_t _prot)
> +{
> +       unsigned long prot = pgprot_val(_prot);
> +
> +       prot &= ~_PAGE_MASK;
> +       prot |= _PAGE_NOCACHE;
> +
> +       return __pgprot(prot);
> +}
> +
>  /*
>   * THP functions
>   */
> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> index d959d207a40d..fa7480cb8b87 100644
> --- a/arch/riscv/kernel/cpufeature.c
> +++ b/arch/riscv/kernel/cpufeature.c
> @@ -8,6 +8,7 @@
>
>  #include <linux/bitmap.h>
>  #include <linux/of.h>
> +#include <linux/pgtable.h>
>  #include <asm/processor.h>
>  #include <asm/hwcap.h>
>  #include <asm/smp.h>
> @@ -59,6 +60,38 @@ bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit)
>  }
>  EXPORT_SYMBOL_GPL(__riscv_isa_extension_available);
>
> +static void __init mmu_supports_svpbmt(void)
> +{
> +#if defined(CONFIG_MMU) && defined(CONFIG_64BIT)
> +       struct device_node *node;
> +       const char *str;
> +
> +       for_each_of_cpu_node(node) {
> +               if (of_property_read_string(node, "mmu-type", &str))
> +                       continue;
> +
> +               if (!strncmp(str + 6, "none", 4))
> +                       continue;
> +
> +               if (of_property_read_string(node, "mmu", &str))
> +                       continue;
> +
> +               if (strncmp(str + 6, "svpmbt", 6))
> +                       continue;
> +       }
> +
> +       __svpbmt.pma            = _SVPBMT_PMA;
> +       __svpbmt.nocache        = _SVPBMT_NC;
> +       __svpbmt.io             = _SVPBMT_IO;
> +       __svpbmt.mask           = _SVPBMT_MASK;
> +#endif
> +}
> +
> +static void __init mmu_supports(void)
> +{
> +       mmu_supports_svpbmt();
> +}
> +
>  void __init riscv_fill_hwcap(void)
>  {
>         struct device_node *node;
> @@ -67,6 +100,8 @@ void __init riscv_fill_hwcap(void)
>         size_t i, j, isa_len;
>         static unsigned long isa2hwcap[256] = {0};
>
> +       mmu_supports();
> +
>         isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I;
>         isa2hwcap['m'] = isa2hwcap['M'] = COMPAT_HWCAP_ISA_M;
>         isa2hwcap['a'] = isa2hwcap['A'] = COMPAT_HWCAP_ISA_A;
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index 24b2b8044602..e4e658165ee1 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -854,3 +854,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
>         return vmemmap_populate_basepages(start, end, node, NULL);
>  }
>  #endif
> +
> +#if defined(CONFIG_64BIT)
> +struct __svpbmt_struct __svpbmt __ro_after_init;
> +EXPORT_SYMBOL(__svpbmt);
> +#endif
> --
> 2.25.4
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt

[Heiko Stübner]

Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt:
> On 11/29/21 02:40, wefu@redhat.com wrote:
> > From: Wei Fu <wefu@redhat.com>
> > 
> > Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt"
> > in the DT mmu node. Update dt-bindings related property here.
> > 
> > Signed-off-by: Wei Fu <wefu@redhat.com>
> > Co-developed-by: Guo Ren <guoren@kernel.org>
> > Signed-off-by: Guo Ren <guoren@kernel.org>
> > Cc: Anup Patel <anup@brainfault.org>
> > Cc: Palmer Dabbelt <palmer@dabbelt.com>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > ---
> >   Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++
> >   1 file changed, 10 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > index aa5fb64d57eb..9ff9cbdd8a85 100644
> > --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> > +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > @@ -63,6 +63,16 @@ properties:
> >         - riscv,sv48
> >         - riscv,none
> >   
> > +  mmu:
> 
> Shouldn't we keep the items be in alphabetic order, i.e. mmu before 
> mmu-type?
> 
> > +    description:
> > +      Describes the CPU's MMU Standard Extensions support.
> > +      These values originate from the RISC-V Privileged
> > +      Specification document, available from
> > +      https://riscv.org/specifications/
> > +    $ref: '/schemas/types.yaml#/definitions/string'
> > +    enum:
> > +      - riscv,svpmbt
> 
> The privileged specification has multiple MMU related extensions: 
> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum?

I remember in some earlier version some way back there was the
suggestion of using a sub-node instead and then adding boolean
properties for the supported extensions.

Aka something like
	mmu {
		riscv,svpbmt;	
	};

Which I guess would be a lot nicer. Also right now there is string-
comparison done on the code side, which would look way easier
when just looking for booleans in the dt instead.

Also isn't an enum a "one-of" selection, so wouldn't work directly
for multiple extensions?


Heiko


> 
> Best regards
> 
> Heinrich
> 
> > +
> >     riscv,isa:
> >       description:
> >         Identifies the specific RISC-V instruction set architecture
> > 
> 
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
> 

Re: [PATCH V4 0/2] riscv: add RISC-V Svpbmt Standard Extension supports

[Jisheng Zhang]

On Mon, 29 Nov 2021 09:40:05 +0800
wefu@redhat.com wrote:

> From: Fu Wei <wefu@redhat.com>
> 
> This patch follows the  RISC-V standard Svpbmt extension in 
> privilege spec to solve the non-coherent SOC DMA synchronization
> issues.
> 
> The svpbmt PTE format:
> | 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
>   N     MT     RSW    D   A   G   U   X   W   R   V
>         ^
> 
> Of the Reserved bits [63:54] in a leaf PTE, the bits [62:61] are used as
> the MT (aka MemType) field. This field specifies one of three memory types
> as shown in the following table：
> MemType     RISC-V Description
> ----------  ------------------------------------------------
> 00 - PMA    Normal Cacheable, No change to implied PMA memory type
> 01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
> 10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
> 11 - Rsvd   Reserved for future standard use
> 
> The standard protection_map[] needn't be modified because the "PMA"
> type keeps the highest bits zero.
> And the whole modification is limited in the arch/riscv/* and using
> a global variable(__svpbmt) as _PAGE_MASK/IO/NOCACHE for pgprot_noncached
> (&writecombine) in pgtable.h. We also add _PAGE_CHG_MASK to filter
> PFN than before.
> 
> Enable it in devicetree - (Add "riscv,svpbmt" in the mmu of cpu node)
>  - mmu:
>      riscv,svpmbt
> 

I noticed that this series goes up to v4 but changes history is missing.
Will you add it?


> Wei Fu (2):
>   dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt
>   riscv: add RISC-V Svpbmt extension supports
> 
>  .../devicetree/bindings/riscv/cpus.yaml       | 10 +++++
>  arch/riscv/include/asm/fixmap.h               |  2 +-
>  arch/riscv/include/asm/pgtable-64.h           | 21 ++++++++--
>  arch/riscv/include/asm/pgtable-bits.h         | 39 ++++++++++++++++++-
>  arch/riscv/include/asm/pgtable.h              | 39 ++++++++++++++-----
>  arch/riscv/kernel/cpufeature.c                | 35 +++++++++++++++++
>  arch/riscv/mm/init.c                          |  5 +++
>  7 files changed, 136 insertions(+), 15 deletions(-)
> 

Re: [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports

[Jisheng Zhang]

On Mon, 29 Nov 2021 09:40:07 +0800
wefu@redhat.com wrote:

> From: Wei Fu <wefu@redhat.com>
> 
> This patch follows the standard pure RISC-V Svpbmt extension in
> privilege spec to solve the non-coherent SOC dma synchronization
> issues.
> 
> Here is the svpbmt PTE format:
> | 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
>   N     MT     RSW    D   A   G   U   X   W   R   V
>         ^
> 
> Of the Reserved bits [63:54] in a leaf PTE, the high bit is already
> allocated (as the N bit), so bits [62:61] are used as the MT (aka
> MemType) field. This field specifies one of three memory types that
> are close equivalents (or equivalent in effect) to the three main x86
> and ARMv8 memory types - as shown in the following table.
> 
> RISC-V
> Encoding &
> MemType     RISC-V Description
> ----------  ------------------------------------------------
> 00 - PMA    Normal Cacheable, No change to implied PMA memory type
> 01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
> 10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
> 11 - Rsvd   Reserved for future standard use
> 
> The standard protection_map[] needn't be modified because the "PMA"
> type keeps the highest bits zero. And the whole modification is
> limited in the arch/riscv/* and using a global variable
> (__svpbmt) as _PAGE_MASK/IO/NOCACHE for pgprot_noncached
> (&writecombine) in pgtable.h. We also add _PAGE_CHG_MASK to filter
> PFN than before.
> 
> Enable it in devicetree - (Add "riscv,svpbmt" in the mmu of cpu node)
>  - mmu:
>      riscv,svpmbt
> 
> Signed-off-by: Wei Fu <wefu@redhat.com>
> Co-developed-by: Liu Shaohua <liush@allwinnertech.com>
> Signed-off-by: Liu Shaohua <liush@allwinnertech.com>
> Co-developed-by: Guo Ren <guoren@kernel.org>
> Signed-off-by: Guo Ren <guoren@kernel.org>
> Cc: Palmer Dabbelt <palmerdabbelt@google.com>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Anup Patel <anup.patel@wdc.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Atish Patra <atish.patra@wdc.com>
> Cc: Drew Fustini <drew@beagleboard.org>
> Cc: Wei Fu <wefu@redhat.com>
> Cc: Wei Wu <lazyparser@gmail.com>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Cc: Maxime Ripard <maxime@cerno.tech>
> Cc: Daniel Lustig <dlustig@nvidia.com>
> Cc: Greg Favor <gfavor@ventanamicro.com>
> Cc: Andrea Mondelli <andrea.mondelli@huawei.com>
> Cc: Jonathan Behrens <behrensj@mit.edu>
> Cc: Xinhaoqu (Freddie) <xinhaoqu@huawei.com>
> Cc: Bill Huffman <huffman@cadence.com>
> Cc: Nick Kossifidis <mick@ics.forth.gr>
> Cc: Allen Baum <allen.baum@esperantotech.com>
> Cc: Josh Scheid <jscheid@ventanamicro.com>
> Cc: Richard Trauben <rtrauben@gmail.com>
> ---
>  arch/riscv/include/asm/fixmap.h       |  2 +-
>  arch/riscv/include/asm/pgtable-64.h   | 21 ++++++++++++---
>  arch/riscv/include/asm/pgtable-bits.h | 39 +++++++++++++++++++++++++--
>  arch/riscv/include/asm/pgtable.h      | 39 ++++++++++++++++++++-------
>  arch/riscv/kernel/cpufeature.c        | 35 ++++++++++++++++++++++++
>  arch/riscv/mm/init.c                  |  5 ++++
>  6 files changed, 126 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h
> index 54cbf07fb4e9..5acd99d08e74 100644
> --- a/arch/riscv/include/asm/fixmap.h
> +++ b/arch/riscv/include/asm/fixmap.h
> @@ -43,7 +43,7 @@ enum fixed_addresses {
>  	__end_of_fixed_addresses
>  };
>  
> -#define FIXMAP_PAGE_IO		PAGE_KERNEL
> +#define FIXMAP_PAGE_IO		PAGE_IOREMAP
>  
>  #define __early_set_fixmap	__set_fixmap
>  
> diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h
> index 228261aa9628..16d251282b1d 100644
> --- a/arch/riscv/include/asm/pgtable-64.h
> +++ b/arch/riscv/include/asm/pgtable-64.h
> @@ -59,14 +59,29 @@ static inline void pud_clear(pud_t *pudp)
>  	set_pud(pudp, __pud(0));
>  }
>  
> +static inline unsigned long _chg_of_pmd(pmd_t pmd)
> +{
> +	return (pmd_val(pmd) & _PAGE_CHG_MASK);
> +}
> +
> +static inline unsigned long _chg_of_pud(pud_t pud)
> +{
> +	return (pud_val(pud) & _PAGE_CHG_MASK);
> +}
> +
> +static inline unsigned long _chg_of_pte(pte_t pte)
> +{
> +	return (pte_val(pte) & _PAGE_CHG_MASK);
> +}
> +
>  static inline pmd_t *pud_pgtable(pud_t pud)
>  {
> -	return (pmd_t *)pfn_to_virt(pud_val(pud) >> _PAGE_PFN_SHIFT);
> +	return (pmd_t *)pfn_to_virt(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT);
>  }
>  
>  static inline struct page *pud_page(pud_t pud)
>  {
> -	return pfn_to_page(pud_val(pud) >> _PAGE_PFN_SHIFT);
> +	return pfn_to_page(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT);
>  }
>  
>  static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot)
> @@ -76,7 +91,7 @@ static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot)
>  
>  static inline unsigned long _pmd_pfn(pmd_t pmd)
>  {
> -	return pmd_val(pmd) >> _PAGE_PFN_SHIFT;
> +	return _chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT;
>  }
>  
>  #define mk_pmd(page, prot)    pfn_pmd(page_to_pfn(page), prot)
> diff --git a/arch/riscv/include/asm/pgtable-bits.h b/arch/riscv/include/asm/pgtable-bits.h
> index 2ee413912926..e5b0fce4ddc5 100644
> --- a/arch/riscv/include/asm/pgtable-bits.h
> +++ b/arch/riscv/include/asm/pgtable-bits.h
> @@ -7,7 +7,7 @@
>  #define _ASM_RISCV_PGTABLE_BITS_H
>  
>  /*
> - * PTE format:
> + * rv32 PTE format:
>   * | XLEN-1  10 | 9             8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
>   *       PFN      reserved for SW   D   A   G   U   X   W   R   V
>   */
> @@ -24,6 +24,40 @@
>  #define _PAGE_DIRTY     (1 << 7)    /* Set by hardware on any write */
>  #define _PAGE_SOFT      (1 << 8)    /* Reserved for software */
>  
> +#if !defined(__ASSEMBLY__) && defined(CONFIG_64BIT)
> +/*
> + * rv64 PTE format:
> + * | 63 | 62 61 | 60 54 | 53  10 | 9             8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
> + *   N      MT     RSV    PFN      reserved for SW   D   A   G   U   X   W   R   V
> + * [62:61] Memory Type definitions:
> + *  00 - PMA    Normal Cacheable, No change to implied PMA memory type
> + *  01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
> + *  10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
> + *  11 - Rsvd   Reserved for future standard use
> + */
> +#define _SVPBMT_PMA		0UL
> +#define _SVPBMT_NC		(1UL << 61)
> +#define _SVPBMT_IO		(1UL << 62)
> +#define _SVPBMT_MASK		(_SVPBMT_NC | _SVPBMT_IO)
> +
> +extern struct __svpbmt_struct {
> +	unsigned long mask;
> +	unsigned long pma;
> +	unsigned long nocache;
> +	unsigned long io;
> +} __svpbmt __cacheline_aligned;
> +
> +#define _PAGE_MASK		__svpbmt.mask
> +#define _PAGE_PMA		__svpbmt.pma
> +#define _PAGE_NOCACHE		__svpbmt.nocache
> +#define _PAGE_IO		__svpbmt.io
> +#else
> +#define _PAGE_MASK		0
> +#define _PAGE_PMA		0
> +#define _PAGE_NOCACHE		0
> +#define _PAGE_IO		0
> +#endif /* !__ASSEMBLY__ && CONFIG_64BIT */
> +
>  #define _PAGE_SPECIAL   _PAGE_SOFT
>  #define _PAGE_TABLE     _PAGE_PRESENT
>  
> @@ -38,7 +72,8 @@
>  /* Set of bits to preserve across pte_modify() */
>  #define _PAGE_CHG_MASK  (~(unsigned long)(_PAGE_PRESENT | _PAGE_READ |	\
>  					  _PAGE_WRITE | _PAGE_EXEC |	\
> -					  _PAGE_USER | _PAGE_GLOBAL))
> +					  _PAGE_USER | _PAGE_GLOBAL |	\
> +					  _PAGE_MASK))
>  /*
>   * when all of R/W/X are zero, the PTE is a pointer to the next level
>   * of the page table; otherwise, it is a leaf PTE.
> diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
> index bf204e7c1f74..0f7a6541015f 100644
> --- a/arch/riscv/include/asm/pgtable.h
> +++ b/arch/riscv/include/asm/pgtable.h
> @@ -138,7 +138,8 @@
>  				| _PAGE_PRESENT \
>  				| _PAGE_ACCESSED \
>  				| _PAGE_DIRTY \
> -				| _PAGE_GLOBAL)
> +				| _PAGE_GLOBAL \
> +				| _PAGE_PMA)
>  
>  #define PAGE_KERNEL		__pgprot(_PAGE_KERNEL)
>  #define PAGE_KERNEL_READ	__pgprot(_PAGE_KERNEL & ~_PAGE_WRITE)
> @@ -148,11 +149,9 @@
>  
>  #define PAGE_TABLE		__pgprot(_PAGE_TABLE)
>  
> -/*
> - * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't
> - * change the properties of memory regions.
> - */
> -#define _PAGE_IOREMAP _PAGE_KERNEL
> +#define _PAGE_IOREMAP	((_PAGE_KERNEL & ~_PAGE_MASK) | _PAGE_IO)
> +
> +#define PAGE_IOREMAP		__pgprot(_PAGE_IOREMAP)
>  
>  extern pgd_t swapper_pg_dir[];
>  
> @@ -232,12 +231,12 @@ static inline unsigned long _pgd_pfn(pgd_t pgd)
>  
>  static inline struct page *pmd_page(pmd_t pmd)
>  {
> -	return pfn_to_page(pmd_val(pmd) >> _PAGE_PFN_SHIFT);
> +	return pfn_to_page(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT);
>  }
>  
>  static inline unsigned long pmd_page_vaddr(pmd_t pmd)
>  {
> -	return (unsigned long)pfn_to_virt(pmd_val(pmd) >> _PAGE_PFN_SHIFT);
> +	return (unsigned long)pfn_to_virt(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT);
>  }
>  
>  static inline pte_t pmd_pte(pmd_t pmd)
> @@ -253,7 +252,7 @@ static inline pte_t pud_pte(pud_t pud)
>  /* Yields the page frame number (PFN) of a page table entry */
>  static inline unsigned long pte_pfn(pte_t pte)
>  {
> -	return (pte_val(pte) >> _PAGE_PFN_SHIFT);
> +	return (_chg_of_pte(pte) >> _PAGE_PFN_SHIFT);
>  }
>  
>  #define pte_page(x)     pfn_to_page(pte_pfn(x))
> @@ -492,6 +491,28 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma,
>  	return ptep_test_and_clear_young(vma, address, ptep);
>  }
>  
> +#define pgprot_noncached pgprot_noncached
> +static inline pgprot_t pgprot_noncached(pgprot_t _prot)
> +{
> +	unsigned long prot = pgprot_val(_prot);
> +
> +	prot &= ~_PAGE_MASK;
> +	prot |= _PAGE_IO;
> +
> +	return __pgprot(prot);
> +}
> +
> +#define pgprot_writecombine pgprot_writecombine
> +static inline pgprot_t pgprot_writecombine(pgprot_t _prot)
> +{
> +	unsigned long prot = pgprot_val(_prot);
> +
> +	prot &= ~_PAGE_MASK;
> +	prot |= _PAGE_NOCACHE;
> +
> +	return __pgprot(prot);
> +}
> +
>  /*
>   * THP functions
>   */
> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> index d959d207a40d..fa7480cb8b87 100644
> --- a/arch/riscv/kernel/cpufeature.c
> +++ b/arch/riscv/kernel/cpufeature.c
> @@ -8,6 +8,7 @@
>  
>  #include <linux/bitmap.h>
>  #include <linux/of.h>
> +#include <linux/pgtable.h>
>  #include <asm/processor.h>
>  #include <asm/hwcap.h>
>  #include <asm/smp.h>
> @@ -59,6 +60,38 @@ bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit)
>  }
>  EXPORT_SYMBOL_GPL(__riscv_isa_extension_available);
>  
> +static void __init mmu_supports_svpbmt(void)
> +{
> +#if defined(CONFIG_MMU) && defined(CONFIG_64BIT)

IIRC, Christoph suggested a CONFIG_RISCV_SVPBMT when reviewing v3. What
about that idea?

> +	struct device_node *node;
> +	const char *str;
> +
> +	for_each_of_cpu_node(node) {
> +		if (of_property_read_string(node, "mmu-type", &str))
> +			continue;
> +
> +		if (!strncmp(str + 6, "none", 4))
> +			continue;
> +
> +		if (of_property_read_string(node, "mmu", &str))
> +			continue;
> +
> +		if (strncmp(str + 6, "svpmbt", 6))
> +			continue;
> +	}
> +
> +	__svpbmt.pma		= _SVPBMT_PMA;
> +	__svpbmt.nocache	= _SVPBMT_NC;
> +	__svpbmt.io		= _SVPBMT_IO;
> +	__svpbmt.mask		= _SVPBMT_MASK;
> +#endif
> +}
> +
> +static void __init mmu_supports(void)

can we remove this function currently? Instead, directly call
mmu_supports_svpbmt()?

> +{
> +	mmu_supports_svpbmt();
> +}
> +
>  void __init riscv_fill_hwcap(void)
>  {
>  	struct device_node *node;
> @@ -67,6 +100,8 @@ void __init riscv_fill_hwcap(void)
>  	size_t i, j, isa_len;
>  	static unsigned long isa2hwcap[256] = {0};
>  
> +	mmu_supports();
> +
>  	isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I;
>  	isa2hwcap['m'] = isa2hwcap['M'] = COMPAT_HWCAP_ISA_M;
>  	isa2hwcap['a'] = isa2hwcap['A'] = COMPAT_HWCAP_ISA_A;
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index 24b2b8044602..e4e658165ee1 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -854,3 +854,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
>  	return vmemmap_populate_basepages(start, end, node, NULL);
>  }
>  #endif
> +
> +#if defined(CONFIG_64BIT)
> +struct __svpbmt_struct __svpbmt __ro_after_init;

Added the structure for all RV64 including NOMMU case and those platforms
which doen't want SVPBMT at all, I believe Christoph's CONFIG_RISCV_SVPBMT
suggestion can solve this problem.

> +EXPORT_SYMBOL(__svpbmt);
> +#endif

Re: [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports

[Guo Ren]

Hi,

We forgot fixmap, add below into your patch.

diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h
index 54cbf07fb4e9..899b59bdb9eb 100644
--- a/arch/riscv/include/asm/fixmap.h
+++ b/arch/riscv/include/asm/fixmap.h
@@ -43,8 +43,6 @@ enum fixed_addresses {
        __end_of_fixed_addresses
 };

-#define FIXMAP_PAGE_IO         PAGE_KERNEL
-
 #define __early_set_fixmap     __set_fixmap

 #define __late_set_fixmap      __set_fixmap
diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
index f3c9f9a1c1bb..9bb06384c57f 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -126,6 +126,8 @@
                                | _PAGE_SHARE \
                                | _PAGE_SO)

+#define PAGE_KERNEL_IO         __pgprot(_PAGE_IOREMAP)

On Mon, Nov 29, 2021 at 9:41 AM <wefu@redhat.com> wrote:
>
> From: Wei Fu <wefu@redhat.com>
>
> This patch follows the standard pure RISC-V Svpbmt extension in
> privilege spec to solve the non-coherent SOC dma synchronization
> issues.
>
> Here is the svpbmt PTE format:
> | 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
>   N     MT     RSW    D   A   G   U   X   W   R   V
>         ^
>
> Of the Reserved bits [63:54] in a leaf PTE, the high bit is already
> allocated (as the N bit), so bits [62:61] are used as the MT (aka
> MemType) field. This field specifies one of three memory types that
> are close equivalents (or equivalent in effect) to the three main x86
> and ARMv8 memory types - as shown in the following table.
>
> RISC-V
> Encoding &
> MemType     RISC-V Description
> ----------  ------------------------------------------------
> 00 - PMA    Normal Cacheable, No change to implied PMA memory type
> 01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
> 10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
> 11 - Rsvd   Reserved for future standard use
>
> The standard protection_map[] needn't be modified because the "PMA"
> type keeps the highest bits zero. And the whole modification is
> limited in the arch/riscv/* and using a global variable
> (__svpbmt) as _PAGE_MASK/IO/NOCACHE for pgprot_noncached
> (&writecombine) in pgtable.h. We also add _PAGE_CHG_MASK to filter
> PFN than before.
>
> Enable it in devicetree - (Add "riscv,svpbmt" in the mmu of cpu node)
>  - mmu:
>      riscv,svpmbt
>
> Signed-off-by: Wei Fu <wefu@redhat.com>
> Co-developed-by: Liu Shaohua <liush@allwinnertech.com>
> Signed-off-by: Liu Shaohua <liush@allwinnertech.com>
> Co-developed-by: Guo Ren <guoren@kernel.org>
> Signed-off-by: Guo Ren <guoren@kernel.org>
> Cc: Palmer Dabbelt <palmerdabbelt@google.com>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Anup Patel <anup.patel@wdc.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Atish Patra <atish.patra@wdc.com>
> Cc: Drew Fustini <drew@beagleboard.org>
> Cc: Wei Fu <wefu@redhat.com>
> Cc: Wei Wu <lazyparser@gmail.com>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Cc: Maxime Ripard <maxime@cerno.tech>
> Cc: Daniel Lustig <dlustig@nvidia.com>
> Cc: Greg Favor <gfavor@ventanamicro.com>
> Cc: Andrea Mondelli <andrea.mondelli@huawei.com>
> Cc: Jonathan Behrens <behrensj@mit.edu>
> Cc: Xinhaoqu (Freddie) <xinhaoqu@huawei.com>
> Cc: Bill Huffman <huffman@cadence.com>
> Cc: Nick Kossifidis <mick@ics.forth.gr>
> Cc: Allen Baum <allen.baum@esperantotech.com>
> Cc: Josh Scheid <jscheid@ventanamicro.com>
> Cc: Richard Trauben <rtrauben@gmail.com>
> ---
>  arch/riscv/include/asm/fixmap.h       |  2 +-
>  arch/riscv/include/asm/pgtable-64.h   | 21 ++++++++++++---
>  arch/riscv/include/asm/pgtable-bits.h | 39 +++++++++++++++++++++++++--
>  arch/riscv/include/asm/pgtable.h      | 39 ++++++++++++++++++++-------
>  arch/riscv/kernel/cpufeature.c        | 35 ++++++++++++++++++++++++
>  arch/riscv/mm/init.c                  |  5 ++++
>  6 files changed, 126 insertions(+), 15 deletions(-)
>
> diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h
> index 54cbf07fb4e9..5acd99d08e74 100644
> --- a/arch/riscv/include/asm/fixmap.h
> +++ b/arch/riscv/include/asm/fixmap.h
> @@ -43,7 +43,7 @@ enum fixed_addresses {
>         __end_of_fixed_addresses
>  };
>
> -#define FIXMAP_PAGE_IO         PAGE_KERNEL
> +#define FIXMAP_PAGE_IO         PAGE_IOREMAP
>
>  #define __early_set_fixmap     __set_fixmap
>
> diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h
> index 228261aa9628..16d251282b1d 100644
> --- a/arch/riscv/include/asm/pgtable-64.h
> +++ b/arch/riscv/include/asm/pgtable-64.h
> @@ -59,14 +59,29 @@ static inline void pud_clear(pud_t *pudp)
>         set_pud(pudp, __pud(0));
>  }
>
> +static inline unsigned long _chg_of_pmd(pmd_t pmd)
> +{
> +       return (pmd_val(pmd) & _PAGE_CHG_MASK);
> +}
> +
> +static inline unsigned long _chg_of_pud(pud_t pud)
> +{
> +       return (pud_val(pud) & _PAGE_CHG_MASK);
> +}
> +
> +static inline unsigned long _chg_of_pte(pte_t pte)
> +{
> +       return (pte_val(pte) & _PAGE_CHG_MASK);
> +}
> +
>  static inline pmd_t *pud_pgtable(pud_t pud)
>  {
> -       return (pmd_t *)pfn_to_virt(pud_val(pud) >> _PAGE_PFN_SHIFT);
> +       return (pmd_t *)pfn_to_virt(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT);
>  }
>
>  static inline struct page *pud_page(pud_t pud)
>  {
> -       return pfn_to_page(pud_val(pud) >> _PAGE_PFN_SHIFT);
> +       return pfn_to_page(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT);
>  }
>
>  static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot)
> @@ -76,7 +91,7 @@ static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot)
>
>  static inline unsigned long _pmd_pfn(pmd_t pmd)
>  {
> -       return pmd_val(pmd) >> _PAGE_PFN_SHIFT;
> +       return _chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT;
>  }
>
>  #define mk_pmd(page, prot)    pfn_pmd(page_to_pfn(page), prot)
> diff --git a/arch/riscv/include/asm/pgtable-bits.h b/arch/riscv/include/asm/pgtable-bits.h
> index 2ee413912926..e5b0fce4ddc5 100644
> --- a/arch/riscv/include/asm/pgtable-bits.h
> +++ b/arch/riscv/include/asm/pgtable-bits.h
> @@ -7,7 +7,7 @@
>  #define _ASM_RISCV_PGTABLE_BITS_H
>
>  /*
> - * PTE format:
> + * rv32 PTE format:
>   * | XLEN-1  10 | 9             8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
>   *       PFN      reserved for SW   D   A   G   U   X   W   R   V
>   */
> @@ -24,6 +24,40 @@
>  #define _PAGE_DIRTY     (1 << 7)    /* Set by hardware on any write */
>  #define _PAGE_SOFT      (1 << 8)    /* Reserved for software */
>
> +#if !defined(__ASSEMBLY__) && defined(CONFIG_64BIT)
> +/*
> + * rv64 PTE format:
> + * | 63 | 62 61 | 60 54 | 53  10 | 9             8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
> + *   N      MT     RSV    PFN      reserved for SW   D   A   G   U   X   W   R   V
> + * [62:61] Memory Type definitions:
> + *  00 - PMA    Normal Cacheable, No change to implied PMA memory type
> + *  01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
> + *  10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
> + *  11 - Rsvd   Reserved for future standard use
> + */
> +#define _SVPBMT_PMA            0UL
> +#define _SVPBMT_NC             (1UL << 61)
> +#define _SVPBMT_IO             (1UL << 62)
> +#define _SVPBMT_MASK           (_SVPBMT_NC | _SVPBMT_IO)
> +
> +extern struct __svpbmt_struct {
> +       unsigned long mask;
> +       unsigned long pma;
> +       unsigned long nocache;
> +       unsigned long io;
> +} __svpbmt __cacheline_aligned;
> +
> +#define _PAGE_MASK             __svpbmt.mask
> +#define _PAGE_PMA              __svpbmt.pma
> +#define _PAGE_NOCACHE          __svpbmt.nocache
> +#define _PAGE_IO               __svpbmt.io
> +#else
> +#define _PAGE_MASK             0
> +#define _PAGE_PMA              0
> +#define _PAGE_NOCACHE          0
> +#define _PAGE_IO               0
> +#endif /* !__ASSEMBLY__ && CONFIG_64BIT */
> +
>  #define _PAGE_SPECIAL   _PAGE_SOFT
>  #define _PAGE_TABLE     _PAGE_PRESENT
>
> @@ -38,7 +72,8 @@
>  /* Set of bits to preserve across pte_modify() */
>  #define _PAGE_CHG_MASK  (~(unsigned long)(_PAGE_PRESENT | _PAGE_READ | \
>                                           _PAGE_WRITE | _PAGE_EXEC |    \
> -                                         _PAGE_USER | _PAGE_GLOBAL))
> +                                         _PAGE_USER | _PAGE_GLOBAL |   \
> +                                         _PAGE_MASK))
>  /*
>   * when all of R/W/X are zero, the PTE is a pointer to the next level
>   * of the page table; otherwise, it is a leaf PTE.
> diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
> index bf204e7c1f74..0f7a6541015f 100644
> --- a/arch/riscv/include/asm/pgtable.h
> +++ b/arch/riscv/include/asm/pgtable.h
> @@ -138,7 +138,8 @@
>                                 | _PAGE_PRESENT \
>                                 | _PAGE_ACCESSED \
>                                 | _PAGE_DIRTY \
> -                               | _PAGE_GLOBAL)
> +                               | _PAGE_GLOBAL \
> +                               | _PAGE_PMA)
>
>  #define PAGE_KERNEL            __pgprot(_PAGE_KERNEL)
>  #define PAGE_KERNEL_READ       __pgprot(_PAGE_KERNEL & ~_PAGE_WRITE)
> @@ -148,11 +149,9 @@
>
>  #define PAGE_TABLE             __pgprot(_PAGE_TABLE)
>
> -/*
> - * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't
> - * change the properties of memory regions.
> - */
> -#define _PAGE_IOREMAP _PAGE_KERNEL
> +#define _PAGE_IOREMAP  ((_PAGE_KERNEL & ~_PAGE_MASK) | _PAGE_IO)
> +
> +#define PAGE_IOREMAP           __pgprot(_PAGE_IOREMAP)
>
>  extern pgd_t swapper_pg_dir[];
>
> @@ -232,12 +231,12 @@ static inline unsigned long _pgd_pfn(pgd_t pgd)
>
>  static inline struct page *pmd_page(pmd_t pmd)
>  {
> -       return pfn_to_page(pmd_val(pmd) >> _PAGE_PFN_SHIFT);
> +       return pfn_to_page(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT);
>  }
>
>  static inline unsigned long pmd_page_vaddr(pmd_t pmd)
>  {
> -       return (unsigned long)pfn_to_virt(pmd_val(pmd) >> _PAGE_PFN_SHIFT);
> +       return (unsigned long)pfn_to_virt(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT);
>  }
>
>  static inline pte_t pmd_pte(pmd_t pmd)
> @@ -253,7 +252,7 @@ static inline pte_t pud_pte(pud_t pud)
>  /* Yields the page frame number (PFN) of a page table entry */
>  static inline unsigned long pte_pfn(pte_t pte)
>  {
> -       return (pte_val(pte) >> _PAGE_PFN_SHIFT);
> +       return (_chg_of_pte(pte) >> _PAGE_PFN_SHIFT);
>  }
>
>  #define pte_page(x)     pfn_to_page(pte_pfn(x))
> @@ -492,6 +491,28 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma,
>         return ptep_test_and_clear_young(vma, address, ptep);
>  }
>
> +#define pgprot_noncached pgprot_noncached
> +static inline pgprot_t pgprot_noncached(pgprot_t _prot)
> +{
> +       unsigned long prot = pgprot_val(_prot);
> +
> +       prot &= ~_PAGE_MASK;
> +       prot |= _PAGE_IO;
> +
> +       return __pgprot(prot);
> +}
> +
> +#define pgprot_writecombine pgprot_writecombine
> +static inline pgprot_t pgprot_writecombine(pgprot_t _prot)
> +{
> +       unsigned long prot = pgprot_val(_prot);
> +
> +       prot &= ~_PAGE_MASK;
> +       prot |= _PAGE_NOCACHE;
> +
> +       return __pgprot(prot);
> +}
> +
>  /*
>   * THP functions
>   */
> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> index d959d207a40d..fa7480cb8b87 100644
> --- a/arch/riscv/kernel/cpufeature.c
> +++ b/arch/riscv/kernel/cpufeature.c
> @@ -8,6 +8,7 @@
>
>  #include <linux/bitmap.h>
>  #include <linux/of.h>
> +#include <linux/pgtable.h>
>  #include <asm/processor.h>
>  #include <asm/hwcap.h>
>  #include <asm/smp.h>
> @@ -59,6 +60,38 @@ bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit)
>  }
>  EXPORT_SYMBOL_GPL(__riscv_isa_extension_available);
>
> +static void __init mmu_supports_svpbmt(void)
> +{
> +#if defined(CONFIG_MMU) && defined(CONFIG_64BIT)
> +       struct device_node *node;
> +       const char *str;
> +
> +       for_each_of_cpu_node(node) {
> +               if (of_property_read_string(node, "mmu-type", &str))
> +                       continue;
> +
> +               if (!strncmp(str + 6, "none", 4))
> +                       continue;
> +
> +               if (of_property_read_string(node, "mmu", &str))
> +                       continue;
> +
> +               if (strncmp(str + 6, "svpmbt", 6))
> +                       continue;
> +       }
> +
> +       __svpbmt.pma            = _SVPBMT_PMA;
> +       __svpbmt.nocache        = _SVPBMT_NC;
> +       __svpbmt.io             = _SVPBMT_IO;
> +       __svpbmt.mask           = _SVPBMT_MASK;
> +#endif
> +}
> +
> +static void __init mmu_supports(void)
> +{
> +       mmu_supports_svpbmt();
> +}
> +
>  void __init riscv_fill_hwcap(void)
>  {
>         struct device_node *node;
> @@ -67,6 +100,8 @@ void __init riscv_fill_hwcap(void)
>         size_t i, j, isa_len;
>         static unsigned long isa2hwcap[256] = {0};
>
> +       mmu_supports();
> +
>         isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I;
>         isa2hwcap['m'] = isa2hwcap['M'] = COMPAT_HWCAP_ISA_M;
>         isa2hwcap['a'] = isa2hwcap['A'] = COMPAT_HWCAP_ISA_A;
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index 24b2b8044602..e4e658165ee1 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -854,3 +854,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
>         return vmemmap_populate_basepages(start, end, node, NULL);
>  }
>  #endif
> +
> +#if defined(CONFIG_64BIT)
> +struct __svpbmt_struct __svpbmt __ro_after_init;
> +EXPORT_SYMBOL(__svpbmt);
> +#endif
> --
> 2.25.4
>


-- 
Best Regards
 Guo Ren

ML: https://lore.kernel.org/linux-csky/

Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt

[Heiko Stübner]

Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner:
> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt:
> > On 11/29/21 02:40, wefu@redhat.com wrote:
> > > From: Wei Fu <wefu@redhat.com>
> > > 
> > > Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt"
> > > in the DT mmu node. Update dt-bindings related property here.
> > > 
> > > Signed-off-by: Wei Fu <wefu@redhat.com>
> > > Co-developed-by: Guo Ren <guoren@kernel.org>
> > > Signed-off-by: Guo Ren <guoren@kernel.org>
> > > Cc: Anup Patel <anup@brainfault.org>
> > > Cc: Palmer Dabbelt <palmer@dabbelt.com>
> > > Cc: Rob Herring <robh+dt@kernel.org>
> > > ---
> > >   Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++
> > >   1 file changed, 10 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > index aa5fb64d57eb..9ff9cbdd8a85 100644
> > > --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > @@ -63,6 +63,16 @@ properties:
> > >         - riscv,sv48
> > >         - riscv,none
> > >   
> > > +  mmu:
> > 
> > Shouldn't we keep the items be in alphabetic order, i.e. mmu before 
> > mmu-type?
> > 
> > > +    description:
> > > +      Describes the CPU's MMU Standard Extensions support.
> > > +      These values originate from the RISC-V Privileged
> > > +      Specification document, available from
> > > +      https://riscv.org/specifications/
> > > +    $ref: '/schemas/types.yaml#/definitions/string'
> > > +    enum:
> > > +      - riscv,svpmbt
> > 
> > The privileged specification has multiple MMU related extensions: 
> > Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum?
> 
> I remember in some earlier version some way back there was the
> suggestion of using a sub-node instead and then adding boolean
> properties for the supported extensions.
> 
> Aka something like
> 	mmu {
> 		riscv,svpbmt;	
> 	};

For the record, I'm talking about the mail from september
https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/

So having a sub-node would make adding future extensions
way nicer.

> 
> Which I guess would be a lot nicer. Also right now there is string-
> comparison done on the code side, which would look way easier
> when just looking for booleans in the dt instead.
> 
> Also isn't an enum a "one-of" selection, so wouldn't work directly
> for multiple extensions?
> 
> 
> Heiko
> 
> 
> > 
> > Best regards
> > 
> > Heinrich
> > 
> > > +
> > >     riscv,isa:
> > >       description:
> > >         Identifies the specific RISC-V instruction set architecture
> > > 
> > 
> > 
> > _______________________________________________
> > linux-riscv mailing list
> > linux-riscv@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
> > 
> 
> 
> 
> 
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
> 

Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt

[Jessica Clarke]

On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote:
> 
> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner:
>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt:
>>> On 11/29/21 02:40, wefu@redhat.com wrote:
>>>> From: Wei Fu <wefu@redhat.com>
>>>> 
>>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt"
>>>> in the DT mmu node. Update dt-bindings related property here.
>>>> 
>>>> Signed-off-by: Wei Fu <wefu@redhat.com>
>>>> Co-developed-by: Guo Ren <guoren@kernel.org>
>>>> Signed-off-by: Guo Ren <guoren@kernel.org>
>>>> Cc: Anup Patel <anup@brainfault.org>
>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com>
>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>> ---
>>>>  Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++
>>>>  1 file changed, 10 insertions(+)
>>>> 
>>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644
>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
>>>> @@ -63,6 +63,16 @@ properties:
>>>>        - riscv,sv48
>>>>        - riscv,none
>>>> 
>>>> +  mmu:
>>> 
>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before 
>>> mmu-type?
>>> 
>>>> +    description:
>>>> +      Describes the CPU's MMU Standard Extensions support.
>>>> +      These values originate from the RISC-V Privileged
>>>> +      Specification document, available from
>>>> +      https://riscv.org/specifications/
>>>> +    $ref: '/schemas/types.yaml#/definitions/string'
>>>> +    enum:
>>>> +      - riscv,svpmbt
>>> 
>>> The privileged specification has multiple MMU related extensions: 
>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum?
>> 
>> I remember in some earlier version some way back there was the
>> suggestion of using a sub-node instead and then adding boolean
>> properties for the supported extensions.
>> 
>> Aka something like
>> 	mmu {
>> 		riscv,svpbmt;	
>> 	};
> 
> For the record, I'm talking about the mail from september
> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/
> 
> So having a sub-node would make adding future extensions
> way nicer.

Svpbmt is just an ISA extension, and should be treated like any other.
Let’s not invent two different ways of representing that in the device
tree.

Jess

Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt

[Heiko Stübner]

Hi,

Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke:
> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote:
> > 
> > Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner:
> >> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt:
> >>> On 11/29/21 02:40, wefu@redhat.com wrote:
> >>>> From: Wei Fu <wefu@redhat.com>
> >>>> 
> >>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt"
> >>>> in the DT mmu node. Update dt-bindings related property here.
> >>>> 
> >>>> Signed-off-by: Wei Fu <wefu@redhat.com>
> >>>> Co-developed-by: Guo Ren <guoren@kernel.org>
> >>>> Signed-off-by: Guo Ren <guoren@kernel.org>
> >>>> Cc: Anup Patel <anup@brainfault.org>
> >>>> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> >>>> Cc: Rob Herring <robh+dt@kernel.org>
> >>>> ---
> >>>>  Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++
> >>>>  1 file changed, 10 insertions(+)
> >>>> 
> >>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> >>>> index aa5fb64d57eb..9ff9cbdd8a85 100644
> >>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> >>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> >>>> @@ -63,6 +63,16 @@ properties:
> >>>>        - riscv,sv48
> >>>>        - riscv,none
> >>>> 
> >>>> +  mmu:
> >>> 
> >>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before 
> >>> mmu-type?
> >>> 
> >>>> +    description:
> >>>> +      Describes the CPU's MMU Standard Extensions support.
> >>>> +      These values originate from the RISC-V Privileged
> >>>> +      Specification document, available from
> >>>> +      https://riscv.org/specifications/
> >>>> +    $ref: '/schemas/types.yaml#/definitions/string'
> >>>> +    enum:
> >>>> +      - riscv,svpmbt
> >>> 
> >>> The privileged specification has multiple MMU related extensions: 
> >>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum?
> >> 
> >> I remember in some earlier version some way back there was the
> >> suggestion of using a sub-node instead and then adding boolean
> >> properties for the supported extensions.
> >> 
> >> Aka something like
> >> 	mmu {
> >> 		riscv,svpbmt;	
> >> 	};
> > 
> > For the record, I'm talking about the mail from september
> > https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/
> > 
> > So having a sub-node would make adding future extensions
> > way nicer.
> 
> Svpbmt is just an ISA extension, and should be treated like any other.
> Let’s not invent two different ways of representing that in the device
> tree.

Heinrich asked how the other extensions should be handled
(Svnapot, Svpbmt, Svinval), so what do you suggest to do with these?


Thanks
Heiko

Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt

[Jessica Clarke]

On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote:
> 
> Hi,
> 
> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke:
>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote:
>>> 
>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner:
>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt:
>>>>> On 11/29/21 02:40, wefu@redhat.com wrote:
>>>>>> From: Wei Fu <wefu@redhat.com>
>>>>>> 
>>>>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt"
>>>>>> in the DT mmu node. Update dt-bindings related property here.
>>>>>> 
>>>>>> Signed-off-by: Wei Fu <wefu@redhat.com>
>>>>>> Co-developed-by: Guo Ren <guoren@kernel.org>
>>>>>> Signed-off-by: Guo Ren <guoren@kernel.org>
>>>>>> Cc: Anup Patel <anup@brainfault.org>
>>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com>
>>>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>>>> ---
>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++
>>>>>> 1 file changed, 10 insertions(+)
>>>>>> 
>>>>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644
>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
>>>>>> @@ -63,6 +63,16 @@ properties:
>>>>>>       - riscv,sv48
>>>>>>       - riscv,none
>>>>>> 
>>>>>> +  mmu:
>>>>> 
>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before 
>>>>> mmu-type?
>>>>> 
>>>>>> +    description:
>>>>>> +      Describes the CPU's MMU Standard Extensions support.
>>>>>> +      These values originate from the RISC-V Privileged
>>>>>> +      Specification document, available from
>>>>>> +      https://riscv.org/specifications/
>>>>>> +    $ref: '/schemas/types.yaml#/definitions/string'
>>>>>> +    enum:
>>>>>> +      - riscv,svpmbt
>>>>> 
>>>>> The privileged specification has multiple MMU related extensions: 
>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum?
>>>> 
>>>> I remember in some earlier version some way back there was the
>>>> suggestion of using a sub-node instead and then adding boolean
>>>> properties for the supported extensions.
>>>> 
>>>> Aka something like
>>>> 	mmu {
>>>> 		riscv,svpbmt;	
>>>> 	};
>>> 
>>> For the record, I'm talking about the mail from september
>>> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/
>>> 
>>> So having a sub-node would make adding future extensions
>>> way nicer.
>> 
>> Svpbmt is just an ISA extension, and should be treated like any other.
>> Let’s not invent two different ways of representing that in the device
>> tree.
> 
> Heinrich asked how the other extensions should be handled
> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with these?

Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may not be
a concrete plan for that yet, but that means you should speak with the
people involved with such extensions and come up with something
appropriate together.

Jess

Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt

[Philipp Tomsich]

We did touch on this in our coordination call a few weeks ago: the
grouping under mmu and the bool-entries were chosen because of their
similarity to other extensions (i.e. for Zb[abcs] there could/should
be a bool-entry under each cpu-node — for some Zv* entries a subnode
might be needed with further parameters).

The string-based approach (as in the originally proposed "mmu-type=")
would like not scale with the proliferation of small & modular
extensions.

Philipp.


On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com> wrote:
>
> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote:
> >
> > Hi,
> >
> > Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke:
> >> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote:
> >>>
> >>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner:
> >>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt:
> >>>>> On 11/29/21 02:40, wefu@redhat.com wrote:
> >>>>>> From: Wei Fu <wefu@redhat.com>
> >>>>>>
> >>>>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt"
> >>>>>> in the DT mmu node. Update dt-bindings related property here.
> >>>>>>
> >>>>>> Signed-off-by: Wei Fu <wefu@redhat.com>
> >>>>>> Co-developed-by: Guo Ren <guoren@kernel.org>
> >>>>>> Signed-off-by: Guo Ren <guoren@kernel.org>
> >>>>>> Cc: Anup Patel <anup@brainfault.org>
> >>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> >>>>>> Cc: Rob Herring <robh+dt@kernel.org>
> >>>>>> ---
> >>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++
> >>>>>> 1 file changed, 10 insertions(+)
> >>>>>>
> >>>>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> >>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644
> >>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> >>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> >>>>>> @@ -63,6 +63,16 @@ properties:
> >>>>>>       - riscv,sv48
> >>>>>>       - riscv,none
> >>>>>>
> >>>>>> +  mmu:
> >>>>>
> >>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before
> >>>>> mmu-type?
> >>>>>
> >>>>>> +    description:
> >>>>>> +      Describes the CPU's MMU Standard Extensions support.
> >>>>>> +      These values originate from the RISC-V Privileged
> >>>>>> +      Specification document, available from
> >>>>>> +      https://riscv.org/specifications/
> >>>>>> +    $ref: '/schemas/types.yaml#/definitions/string'
> >>>>>> +    enum:
> >>>>>> +      - riscv,svpmbt
> >>>>>
> >>>>> The privileged specification has multiple MMU related extensions:
> >>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum?
> >>>>
> >>>> I remember in some earlier version some way back there was the
> >>>> suggestion of using a sub-node instead and then adding boolean
> >>>> properties for the supported extensions.
> >>>>
> >>>> Aka something like
> >>>>    mmu {
> >>>>            riscv,svpbmt;
> >>>>    };
> >>>
> >>> For the record, I'm talking about the mail from september
> >>> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/
> >>>
> >>> So having a sub-node would make adding future extensions
> >>> way nicer.
> >>
> >> Svpbmt is just an ISA extension, and should be treated like any other.
> >> Let’s not invent two different ways of representing that in the device
> >> tree.
> >
> > Heinrich asked how the other extensions should be handled
> > (Svnapot, Svpbmt, Svinval), so what do you suggest to do with these?
>
> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may not be
> a concrete plan for that yet, but that means you should speak with the
> people involved with such extensions and come up with something
> appropriate together.
>
> Jess
>

Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt

[Jessica Clarke]

On 30 Nov 2021, at 15:01, Philipp Tomsich <philipp.tomsich@vrull.eu> wrote:
> 
> We did touch on this in our coordination call a few weeks ago: the
> grouping under mmu and the bool-entries were chosen because of their
> similarity to other extensions (i.e. for Zb[abcs] there could/should
> be a bool-entry under each cpu-node — for some Zv* entries a subnode
> might be needed with further parameters).
> 
> The string-based approach (as in the originally proposed "mmu-type=")
> would like not scale with the proliferation of small & modular
> extensions.

I don’t see why the Sv* extensions need to be under an mmu node then,
unless the intent is that every extension be grouped under a sub-node
(which doesn’t seem viable due to extensions like Zbk*, unless you
group by Ss, Sv and Z)?

Also, what is going to happen to the current riscv,isa? Will that
continue to exist and duplicate the info, or will kernels be required
to reconstruct the string themselves if they want to display it to
users?

As a FreeBSD developer I’m obviously not a part of many of these
discussions, but what the Linux community imposes as the device tree
bindings has a real impact on us.

Jess

> On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com> wrote:
>> 
>> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote:
>>> 
>>> Hi,
>>> 
>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke:
>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote:
>>>>> 
>>>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner:
>>>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt:
>>>>>>> On 11/29/21 02:40, wefu@redhat.com wrote:
>>>>>>>> From: Wei Fu <wefu@redhat.com>
>>>>>>>> 
>>>>>>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt"
>>>>>>>> in the DT mmu node. Update dt-bindings related property here.
>>>>>>>> 
>>>>>>>> Signed-off-by: Wei Fu <wefu@redhat.com>
>>>>>>>> Co-developed-by: Guo Ren <guoren@kernel.org>
>>>>>>>> Signed-off-by: Guo Ren <guoren@kernel.org>
>>>>>>>> Cc: Anup Patel <anup@brainfault.org>
>>>>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com>
>>>>>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>>>>>> ---
>>>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++
>>>>>>>> 1 file changed, 10 insertions(+)
>>>>>>>> 
>>>>>>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
>>>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644
>>>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
>>>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
>>>>>>>> @@ -63,6 +63,16 @@ properties:
>>>>>>>>      - riscv,sv48
>>>>>>>>      - riscv,none
>>>>>>>> 
>>>>>>>> +  mmu:
>>>>>>> 
>>>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before
>>>>>>> mmu-type?
>>>>>>> 
>>>>>>>> +    description:
>>>>>>>> +      Describes the CPU's MMU Standard Extensions support.
>>>>>>>> +      These values originate from the RISC-V Privileged
>>>>>>>> +      Specification document, available from
>>>>>>>> +      https://riscv.org/specifications/
>>>>>>>> +    $ref: '/schemas/types.yaml#/definitions/string'
>>>>>>>> +    enum:
>>>>>>>> +      - riscv,svpmbt
>>>>>>> 
>>>>>>> The privileged specification has multiple MMU related extensions:
>>>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum?
>>>>>> 
>>>>>> I remember in some earlier version some way back there was the
>>>>>> suggestion of using a sub-node instead and then adding boolean
>>>>>> properties for the supported extensions.
>>>>>> 
>>>>>> Aka something like
>>>>>>   mmu {
>>>>>>           riscv,svpbmt;
>>>>>>   };
>>>>> 
>>>>> For the record, I'm talking about the mail from september
>>>>> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/
>>>>> 
>>>>> So having a sub-node would make adding future extensions
>>>>> way nicer.
>>>> 
>>>> Svpbmt is just an ISA extension, and should be treated like any other.
>>>> Let’s not invent two different ways of representing that in the device
>>>> tree.
>>> 
>>> Heinrich asked how the other extensions should be handled
>>> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with these?
>> 
>> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may not be
>> a concrete plan for that yet, but that means you should speak with the
>> people involved with such extensions and come up with something
>> appropriate together.
>> 
>> Jess
>> 

Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt

[Heiko Stübner]

Am Montag, 29. November 2021, 02:40:06 CET schrieb wefu@redhat.com:
> From: Wei Fu <wefu@redhat.com> 
> 
> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt"
> in the DT mmu node. Update dt-bindings related property here.
> 
> Signed-off-by: Wei Fu <wefu@redhat.com>
> Co-developed-by: Guo Ren <guoren@kernel.org>
> Signed-off-by: Guo Ren <guoren@kernel.org>
> Cc: Anup Patel <anup@brainfault.org>
> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> Cc: Rob Herring <robh+dt@kernel.org>
> ---
>  Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> index aa5fb64d57eb..9ff9cbdd8a85 100644
> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> @@ -63,6 +63,16 @@ properties:
>        - riscv,sv48
>        - riscv,none
>  
> +  mmu:
> +    description:
> +      Describes the CPU's MMU Standard Extensions support.
> +      These values originate from the RISC-V Privileged
> +      Specification document, available from
> +      https://riscv.org/specifications/
> +    $ref: '/schemas/types.yaml#/definitions/string'
> +    enum:
> +      - riscv,svpmbt

shouldn't that be "riscv,svpbmt" ? [the m is at the wrong location it seems]

> +
>    riscv,isa:
>      description:
>        Identifies the specific RISC-V instruction set architecture
> 

Re: [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports

[Heiko Stübner]

Am Montag, 29. November 2021, 02:40:07 CET schrieb wefu@redhat.com:
> From: Wei Fu <wefu@redhat.com>
> 
> This patch follows the standard pure RISC-V Svpbmt extension in
> privilege spec to solve the non-coherent SOC dma synchronization
> issues.
> 
> Here is the svpbmt PTE format:
> | 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
>   N     MT     RSW    D   A   G   U   X   W   R   V
>         ^
> 
> Of the Reserved bits [63:54] in a leaf PTE, the high bit is already
> allocated (as the N bit), so bits [62:61] are used as the MT (aka
> MemType) field. This field specifies one of three memory types that
> are close equivalents (or equivalent in effect) to the three main x86
> and ARMv8 memory types - as shown in the following table.
> 
> RISC-V
> Encoding &
> MemType     RISC-V Description
> ----------  ------------------------------------------------
> 00 - PMA    Normal Cacheable, No change to implied PMA memory type
> 01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
> 10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
> 11 - Rsvd   Reserved for future standard use
> 
> The standard protection_map[] needn't be modified because the "PMA"
> type keeps the highest bits zero. And the whole modification is
> limited in the arch/riscv/* and using a global variable
> (__svpbmt) as _PAGE_MASK/IO/NOCACHE for pgprot_noncached
> (&writecombine) in pgtable.h. We also add _PAGE_CHG_MASK to filter
> PFN than before.
> 
> Enable it in devicetree - (Add "riscv,svpbmt" in the mmu of cpu node)
>  - mmu:
>      riscv,svpmbt
> 
> Signed-off-by: Wei Fu <wefu@redhat.com>
> Co-developed-by: Liu Shaohua <liush@allwinnertech.com>
> Signed-off-by: Liu Shaohua <liush@allwinnertech.com>
> Co-developed-by: Guo Ren <guoren@kernel.org>
> Signed-off-by: Guo Ren <guoren@kernel.org>
> Cc: Palmer Dabbelt <palmerdabbelt@google.com>
> Cc: Christoph Hellwig <hch@lst.de>
> Cc: Anup Patel <anup.patel@wdc.com>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Atish Patra <atish.patra@wdc.com>
> Cc: Drew Fustini <drew@beagleboard.org>
> Cc: Wei Fu <wefu@redhat.com>
> Cc: Wei Wu <lazyparser@gmail.com>
> Cc: Chen-Yu Tsai <wens@csie.org>
> Cc: Maxime Ripard <maxime@cerno.tech>
> Cc: Daniel Lustig <dlustig@nvidia.com>
> Cc: Greg Favor <gfavor@ventanamicro.com>
> Cc: Andrea Mondelli <andrea.mondelli@huawei.com>
> Cc: Jonathan Behrens <behrensj@mit.edu>
> Cc: Xinhaoqu (Freddie) <xinhaoqu@huawei.com>
> Cc: Bill Huffman <huffman@cadence.com>
> Cc: Nick Kossifidis <mick@ics.forth.gr>
> Cc: Allen Baum <allen.baum@esperantotech.com>
> Cc: Josh Scheid <jscheid@ventanamicro.com>
> Cc: Richard Trauben <rtrauben@gmail.com>
> ---
>  arch/riscv/include/asm/fixmap.h       |  2 +-
>  arch/riscv/include/asm/pgtable-64.h   | 21 ++++++++++++---
>  arch/riscv/include/asm/pgtable-bits.h | 39 +++++++++++++++++++++++++--
>  arch/riscv/include/asm/pgtable.h      | 39 ++++++++++++++++++++-------
>  arch/riscv/kernel/cpufeature.c        | 35 ++++++++++++++++++++++++
>  arch/riscv/mm/init.c                  |  5 ++++
>  6 files changed, 126 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h
> index 54cbf07fb4e9..5acd99d08e74 100644
> --- a/arch/riscv/include/asm/fixmap.h
> +++ b/arch/riscv/include/asm/fixmap.h
> @@ -43,7 +43,7 @@ enum fixed_addresses {
>  	__end_of_fixed_addresses
>  };
>  
> -#define FIXMAP_PAGE_IO		PAGE_KERNEL
> +#define FIXMAP_PAGE_IO		PAGE_IOREMAP
>  
>  #define __early_set_fixmap	__set_fixmap
>  
> diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h
> index 228261aa9628..16d251282b1d 100644
> --- a/arch/riscv/include/asm/pgtable-64.h
> +++ b/arch/riscv/include/asm/pgtable-64.h
> @@ -59,14 +59,29 @@ static inline void pud_clear(pud_t *pudp)
>  	set_pud(pudp, __pud(0));
>  }
>  
> +static inline unsigned long _chg_of_pmd(pmd_t pmd)
> +{
> +	return (pmd_val(pmd) & _PAGE_CHG_MASK);
> +}
> +
> +static inline unsigned long _chg_of_pud(pud_t pud)
> +{
> +	return (pud_val(pud) & _PAGE_CHG_MASK);
> +}
> +
> +static inline unsigned long _chg_of_pte(pte_t pte)
> +{
> +	return (pte_val(pte) & _PAGE_CHG_MASK);
> +}
> +
>  static inline pmd_t *pud_pgtable(pud_t pud)
>  {
> -	return (pmd_t *)pfn_to_virt(pud_val(pud) >> _PAGE_PFN_SHIFT);
> +	return (pmd_t *)pfn_to_virt(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT);
>  }
>  
>  static inline struct page *pud_page(pud_t pud)
>  {
> -	return pfn_to_page(pud_val(pud) >> _PAGE_PFN_SHIFT);
> +	return pfn_to_page(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT);
>  }
>  
>  static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot)
> @@ -76,7 +91,7 @@ static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot)
>  
>  static inline unsigned long _pmd_pfn(pmd_t pmd)
>  {
> -	return pmd_val(pmd) >> _PAGE_PFN_SHIFT;
> +	return _chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT;
>  }
>  
>  #define mk_pmd(page, prot)    pfn_pmd(page_to_pfn(page), prot)
> diff --git a/arch/riscv/include/asm/pgtable-bits.h b/arch/riscv/include/asm/pgtable-bits.h
> index 2ee413912926..e5b0fce4ddc5 100644
> --- a/arch/riscv/include/asm/pgtable-bits.h
> +++ b/arch/riscv/include/asm/pgtable-bits.h
> @@ -7,7 +7,7 @@
>  #define _ASM_RISCV_PGTABLE_BITS_H
>  
>  /*
> - * PTE format:
> + * rv32 PTE format:
>   * | XLEN-1  10 | 9             8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
>   *       PFN      reserved for SW   D   A   G   U   X   W   R   V
>   */
> @@ -24,6 +24,40 @@
>  #define _PAGE_DIRTY     (1 << 7)    /* Set by hardware on any write */
>  #define _PAGE_SOFT      (1 << 8)    /* Reserved for software */
>  
> +#if !defined(__ASSEMBLY__) && defined(CONFIG_64BIT)
> +/*
> + * rv64 PTE format:
> + * | 63 | 62 61 | 60 54 | 53  10 | 9             8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
> + *   N      MT     RSV    PFN      reserved for SW   D   A   G   U   X   W   R   V
> + * [62:61] Memory Type definitions:
> + *  00 - PMA    Normal Cacheable, No change to implied PMA memory type
> + *  01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
> + *  10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
> + *  11 - Rsvd   Reserved for future standard use
> + */
> +#define _SVPBMT_PMA		0UL
> +#define _SVPBMT_NC		(1UL << 61)
> +#define _SVPBMT_IO		(1UL << 62)
> +#define _SVPBMT_MASK		(_SVPBMT_NC | _SVPBMT_IO)
> +
> +extern struct __svpbmt_struct {
> +	unsigned long mask;
> +	unsigned long pma;
> +	unsigned long nocache;
> +	unsigned long io;
> +} __svpbmt __cacheline_aligned;
> +
> +#define _PAGE_MASK		__svpbmt.mask
> +#define _PAGE_PMA		__svpbmt.pma
> +#define _PAGE_NOCACHE		__svpbmt.nocache
> +#define _PAGE_IO		__svpbmt.io
> +#else
> +#define _PAGE_MASK		0
> +#define _PAGE_PMA		0
> +#define _PAGE_NOCACHE		0
> +#define _PAGE_IO		0
> +#endif /* !__ASSEMBLY__ && CONFIG_64BIT */
> +
>  #define _PAGE_SPECIAL   _PAGE_SOFT
>  #define _PAGE_TABLE     _PAGE_PRESENT
>  
> @@ -38,7 +72,8 @@
>  /* Set of bits to preserve across pte_modify() */
>  #define _PAGE_CHG_MASK  (~(unsigned long)(_PAGE_PRESENT | _PAGE_READ |	\
>  					  _PAGE_WRITE | _PAGE_EXEC |	\
> -					  _PAGE_USER | _PAGE_GLOBAL))
> +					  _PAGE_USER | _PAGE_GLOBAL |	\
> +					  _PAGE_MASK))
>  /*
>   * when all of R/W/X are zero, the PTE is a pointer to the next level
>   * of the page table; otherwise, it is a leaf PTE.
> diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
> index bf204e7c1f74..0f7a6541015f 100644
> --- a/arch/riscv/include/asm/pgtable.h
> +++ b/arch/riscv/include/asm/pgtable.h
> @@ -138,7 +138,8 @@
>  				| _PAGE_PRESENT \
>  				| _PAGE_ACCESSED \
>  				| _PAGE_DIRTY \
> -				| _PAGE_GLOBAL)
> +				| _PAGE_GLOBAL \
> +				| _PAGE_PMA)
>  
>  #define PAGE_KERNEL		__pgprot(_PAGE_KERNEL)
>  #define PAGE_KERNEL_READ	__pgprot(_PAGE_KERNEL & ~_PAGE_WRITE)
> @@ -148,11 +149,9 @@
>  
>  #define PAGE_TABLE		__pgprot(_PAGE_TABLE)
>  
> -/*
> - * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't
> - * change the properties of memory regions.
> - */
> -#define _PAGE_IOREMAP _PAGE_KERNEL
> +#define _PAGE_IOREMAP	((_PAGE_KERNEL & ~_PAGE_MASK) | _PAGE_IO)
> +
> +#define PAGE_IOREMAP		__pgprot(_PAGE_IOREMAP)
>  
>  extern pgd_t swapper_pg_dir[];
>  
> @@ -232,12 +231,12 @@ static inline unsigned long _pgd_pfn(pgd_t pgd)
>  
>  static inline struct page *pmd_page(pmd_t pmd)
>  {
> -	return pfn_to_page(pmd_val(pmd) >> _PAGE_PFN_SHIFT);
> +	return pfn_to_page(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT);
>  }
>  
>  static inline unsigned long pmd_page_vaddr(pmd_t pmd)
>  {
> -	return (unsigned long)pfn_to_virt(pmd_val(pmd) >> _PAGE_PFN_SHIFT);
> +	return (unsigned long)pfn_to_virt(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT);
>  }
>  
>  static inline pte_t pmd_pte(pmd_t pmd)
> @@ -253,7 +252,7 @@ static inline pte_t pud_pte(pud_t pud)
>  /* Yields the page frame number (PFN) of a page table entry */
>  static inline unsigned long pte_pfn(pte_t pte)
>  {
> -	return (pte_val(pte) >> _PAGE_PFN_SHIFT);
> +	return (_chg_of_pte(pte) >> _PAGE_PFN_SHIFT);
>  }
>  
>  #define pte_page(x)     pfn_to_page(pte_pfn(x))
> @@ -492,6 +491,28 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma,
>  	return ptep_test_and_clear_young(vma, address, ptep);
>  }
>  
> +#define pgprot_noncached pgprot_noncached
> +static inline pgprot_t pgprot_noncached(pgprot_t _prot)
> +{
> +	unsigned long prot = pgprot_val(_prot);
> +
> +	prot &= ~_PAGE_MASK;
> +	prot |= _PAGE_IO;
> +
> +	return __pgprot(prot);
> +}
> +
> +#define pgprot_writecombine pgprot_writecombine
> +static inline pgprot_t pgprot_writecombine(pgprot_t _prot)
> +{
> +	unsigned long prot = pgprot_val(_prot);
> +
> +	prot &= ~_PAGE_MASK;
> +	prot |= _PAGE_NOCACHE;
> +
> +	return __pgprot(prot);
> +}
> +
>  /*
>   * THP functions
>   */
> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> index d959d207a40d..fa7480cb8b87 100644
> --- a/arch/riscv/kernel/cpufeature.c
> +++ b/arch/riscv/kernel/cpufeature.c
> @@ -8,6 +8,7 @@
>  
>  #include <linux/bitmap.h>
>  #include <linux/of.h>
> +#include <linux/pgtable.h>
>  #include <asm/processor.h>
>  #include <asm/hwcap.h>
>  #include <asm/smp.h>
> @@ -59,6 +60,38 @@ bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit)
>  }
>  EXPORT_SYMBOL_GPL(__riscv_isa_extension_available);
>  
> +static void __init mmu_supports_svpbmt(void)
> +{
> +#if defined(CONFIG_MMU) && defined(CONFIG_64BIT)
> +	struct device_node *node;
> +	const char *str;
> +
> +	for_each_of_cpu_node(node) {
> +		if (of_property_read_string(node, "mmu-type", &str))
> +			continue;
> +
> +		if (!strncmp(str + 6, "none", 4))
> +			continue;
> +
> +		if (of_property_read_string(node, "mmu", &str))
> +			continue;
> +
> +		if (strncmp(str + 6, "svpmbt", 6))

same here ... check for "svpbmt" [m seems to be at the wrong position]


> +			continue;
> +	}
> +
> +	__svpbmt.pma		= _SVPBMT_PMA;
> +	__svpbmt.nocache	= _SVPBMT_NC;
> +	__svpbmt.io		= _SVPBMT_IO;
> +	__svpbmt.mask		= _SVPBMT_MASK;
> +#endif
> +}
> +
> +static void __init mmu_supports(void)
> +{
> +	mmu_supports_svpbmt();
> +}
> +
>  void __init riscv_fill_hwcap(void)
>  {
>  	struct device_node *node;
> @@ -67,6 +100,8 @@ void __init riscv_fill_hwcap(void)
>  	size_t i, j, isa_len;
>  	static unsigned long isa2hwcap[256] = {0};
>  
> +	mmu_supports();
> +
>  	isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I;
>  	isa2hwcap['m'] = isa2hwcap['M'] = COMPAT_HWCAP_ISA_M;
>  	isa2hwcap['a'] = isa2hwcap['A'] = COMPAT_HWCAP_ISA_A;
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index 24b2b8044602..e4e658165ee1 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -854,3 +854,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
>  	return vmemmap_populate_basepages(start, end, node, NULL);
>  }
>  #endif
> +
> +#if defined(CONFIG_64BIT)
> +struct __svpbmt_struct __svpbmt __ro_after_init;
> +EXPORT_SYMBOL(__svpbmt);
> +#endif
> 

Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt

[Atish Patra]

On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <jrtc27@jrtc27.com> wrote:
>
> On 30 Nov 2021, at 15:01, Philipp Tomsich <philipp.tomsich@vrull.eu> wrote:
> >
> > We did touch on this in our coordination call a few weeks ago: the
> > grouping under mmu and the bool-entries were chosen because of their
> > similarity to other extensions (i.e. for Zb[abcs] there could/should
> > be a bool-entry under each cpu-node — for some Zv* entries a subnode
> > might be needed with further parameters).
> >
> > The string-based approach (as in the originally proposed "mmu-type=")
> > would like not scale with the proliferation of small & modular
> > extensions.
>
> I don’t see why the Sv* extensions need to be under an mmu node then,
> unless the intent is that every extension be grouped under a sub-node
> (which doesn’t seem viable due to extensions like Zbk*, unless you
> group by Ss, Sv and Z)?
>

It shouldn't be. All the ISA extensions (i.e. standard, supervisor & hypervisor)
with prefix S,Z,H should be kept separate in a separate node for easy
parsing.

"riscv,isa" dt property will not scale at all. Just look at the few
extensions that were ratified this year
and Linux kernel needs to support them.

"Sscofpmf", "Svpbmt", "Zicbom"

> Also, what is going to happen to the current riscv,isa? Will that
> continue to exist and duplicate the info, or will kernels be required
> to reconstruct the string themselves if they want to display it to
> users?
>

This is my personal preference:
riscv,isa will continue to base Standard ISA extensions that have
single letter extensions.

This new DT node will encode all the non-single letter extensions.
I am not sure if it should include some provisions for custom
extensions starting with X because
that will be platform specific.

Again, this is just my personal preference. I will try to send a patch
soon so that we can initiate a broader
discussion of the scheme and agree/disagree on something.



> As a FreeBSD developer I’m obviously not a part of many of these
> discussions, but what the Linux community imposes as the device tree
> bindings has a real impact on us.
>
> Jess
>
> > On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com> wrote:
> >>
> >> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke:
> >>>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote:
> >>>>>
> >>>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner:
> >>>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt:
> >>>>>>> On 11/29/21 02:40, wefu@redhat.com wrote:
> >>>>>>>> From: Wei Fu <wefu@redhat.com>
> >>>>>>>>
> >>>>>>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt"
> >>>>>>>> in the DT mmu node. Update dt-bindings related property here.
> >>>>>>>>
> >>>>>>>> Signed-off-by: Wei Fu <wefu@redhat.com>
> >>>>>>>> Co-developed-by: Guo Ren <guoren@kernel.org>
> >>>>>>>> Signed-off-by: Guo Ren <guoren@kernel.org>
> >>>>>>>> Cc: Anup Patel <anup@brainfault.org>
> >>>>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> >>>>>>>> Cc: Rob Herring <robh+dt@kernel.org>
> >>>>>>>> ---
> >>>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++
> >>>>>>>> 1 file changed, 10 insertions(+)
> >>>>>>>>
> >>>>>>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> >>>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644
> >>>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> >>>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> >>>>>>>> @@ -63,6 +63,16 @@ properties:
> >>>>>>>>      - riscv,sv48
> >>>>>>>>      - riscv,none
> >>>>>>>>
> >>>>>>>> +  mmu:
> >>>>>>>
> >>>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before
> >>>>>>> mmu-type?
> >>>>>>>
> >>>>>>>> +    description:
> >>>>>>>> +      Describes the CPU's MMU Standard Extensions support.
> >>>>>>>> +      These values originate from the RISC-V Privileged
> >>>>>>>> +      Specification document, available from
> >>>>>>>> +      https://riscv.org/specifications/
> >>>>>>>> +    $ref: '/schemas/types.yaml#/definitions/string'
> >>>>>>>> +    enum:
> >>>>>>>> +      - riscv,svpmbt
> >>>>>>>
> >>>>>>> The privileged specification has multiple MMU related extensions:
> >>>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum?
> >>>>>>
> >>>>>> I remember in some earlier version some way back there was the
> >>>>>> suggestion of using a sub-node instead and then adding boolean
> >>>>>> properties for the supported extensions.
> >>>>>>
> >>>>>> Aka something like
> >>>>>>   mmu {
> >>>>>>           riscv,svpbmt;
> >>>>>>   };
> >>>>>
> >>>>> For the record, I'm talking about the mail from september
> >>>>> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/
> >>>>>
> >>>>> So having a sub-node would make adding future extensions
> >>>>> way nicer.
> >>>>
> >>>> Svpbmt is just an ISA extension, and should be treated like any other.
> >>>> Let’s not invent two different ways of representing that in the device
> >>>> tree.
> >>>
> >>> Heinrich asked how the other extensions should be handled
> >>> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with these?
> >>
> >> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may not be
> >> a concrete plan for that yet, but that means you should speak with the
> >> people involved with such extensions and come up with something
> >> appropriate together.
> >>
> >> Jess
> >>
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv



--
Regards,
Atish

Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt

[Wei Fu]

Hi Heiko,
Thanks for your correction ,  this was my typo when I did the "sed" to
replace the word.
I need to make a V5 ASAP

On Wed, Dec 1, 2021 at 2:46 AM Heiko Stübner <heiko@sntech.de> wrote:
>
> Am Montag, 29. November 2021, 02:40:06 CET schrieb wefu@redhat.com:
> > From: Wei Fu <wefu@redhat.com>
> >
> > Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt"
> > in the DT mmu node. Update dt-bindings related property here.
> >
> > Signed-off-by: Wei Fu <wefu@redhat.com>
> > Co-developed-by: Guo Ren <guoren@kernel.org>
> > Signed-off-by: Guo Ren <guoren@kernel.org>
> > Cc: Anup Patel <anup@brainfault.org>
> > Cc: Palmer Dabbelt <palmer@dabbelt.com>
> > Cc: Rob Herring <robh+dt@kernel.org>
> > ---
> >  Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > index aa5fb64d57eb..9ff9cbdd8a85 100644
> > --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> > +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > @@ -63,6 +63,16 @@ properties:
> >        - riscv,sv48
> >        - riscv,none
> >
> > +  mmu:
> > +    description:
> > +      Describes the CPU's MMU Standard Extensions support.
> > +      These values originate from the RISC-V Privileged
> > +      Specification document, available from
> > +      https://riscv.org/specifications/
> > +    $ref: '/schemas/types.yaml#/definitions/string'
> > +    enum:
> > +      - riscv,svpmbt
>
> shouldn't that be "riscv,svpbmt" ? [the m is at the wrong location it seems]
>
> > +
> >    riscv,isa:
> >      description:
> >        Identifies the specific RISC-V instruction set architecture
> >
>
>
>
>

Re: [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports

[Wei Fu]

Hi Heiko,
thanks , yup, my typo, fixed in my new version .

On Wed, Dec 1, 2021 at 2:46 AM Heiko Stübner <heiko@sntech.de> wrote:
>
> Am Montag, 29. November 2021, 02:40:07 CET schrieb wefu@redhat.com:
> > From: Wei Fu <wefu@redhat.com>
> >
> > This patch follows the standard pure RISC-V Svpbmt extension in
> > privilege spec to solve the non-coherent SOC dma synchronization
> > issues.
> >
> > Here is the svpbmt PTE format:
> > | 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
> >   N     MT     RSW    D   A   G   U   X   W   R   V
> >         ^
> >
> > Of the Reserved bits [63:54] in a leaf PTE, the high bit is already
> > allocated (as the N bit), so bits [62:61] are used as the MT (aka
> > MemType) field. This field specifies one of three memory types that
> > are close equivalents (or equivalent in effect) to the three main x86
> > and ARMv8 memory types - as shown in the following table.
> >
> > RISC-V
> > Encoding &
> > MemType     RISC-V Description
> > ----------  ------------------------------------------------
> > 00 - PMA    Normal Cacheable, No change to implied PMA memory type
> > 01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
> > 10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
> > 11 - Rsvd   Reserved for future standard use
> >
> > The standard protection_map[] needn't be modified because the "PMA"
> > type keeps the highest bits zero. And the whole modification is
> > limited in the arch/riscv/* and using a global variable
> > (__svpbmt) as _PAGE_MASK/IO/NOCACHE for pgprot_noncached
> > (&writecombine) in pgtable.h. We also add _PAGE_CHG_MASK to filter
> > PFN than before.
> >
> > Enable it in devicetree - (Add "riscv,svpbmt" in the mmu of cpu node)
> >  - mmu:
> >      riscv,svpmbt
> >
> > Signed-off-by: Wei Fu <wefu@redhat.com>
> > Co-developed-by: Liu Shaohua <liush@allwinnertech.com>
> > Signed-off-by: Liu Shaohua <liush@allwinnertech.com>
> > Co-developed-by: Guo Ren <guoren@kernel.org>
> > Signed-off-by: Guo Ren <guoren@kernel.org>
> > Cc: Palmer Dabbelt <palmerdabbelt@google.com>
> > Cc: Christoph Hellwig <hch@lst.de>
> > Cc: Anup Patel <anup.patel@wdc.com>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Atish Patra <atish.patra@wdc.com>
> > Cc: Drew Fustini <drew@beagleboard.org>
> > Cc: Wei Fu <wefu@redhat.com>
> > Cc: Wei Wu <lazyparser@gmail.com>
> > Cc: Chen-Yu Tsai <wens@csie.org>
> > Cc: Maxime Ripard <maxime@cerno.tech>
> > Cc: Daniel Lustig <dlustig@nvidia.com>
> > Cc: Greg Favor <gfavor@ventanamicro.com>
> > Cc: Andrea Mondelli <andrea.mondelli@huawei.com>
> > Cc: Jonathan Behrens <behrensj@mit.edu>
> > Cc: Xinhaoqu (Freddie) <xinhaoqu@huawei.com>
> > Cc: Bill Huffman <huffman@cadence.com>
> > Cc: Nick Kossifidis <mick@ics.forth.gr>
> > Cc: Allen Baum <allen.baum@esperantotech.com>
> > Cc: Josh Scheid <jscheid@ventanamicro.com>
> > Cc: Richard Trauben <rtrauben@gmail.com>
> > ---
> >  arch/riscv/include/asm/fixmap.h       |  2 +-
> >  arch/riscv/include/asm/pgtable-64.h   | 21 ++++++++++++---
> >  arch/riscv/include/asm/pgtable-bits.h | 39 +++++++++++++++++++++++++--
> >  arch/riscv/include/asm/pgtable.h      | 39 ++++++++++++++++++++-------
> >  arch/riscv/kernel/cpufeature.c        | 35 ++++++++++++++++++++++++
> >  arch/riscv/mm/init.c                  |  5 ++++
> >  6 files changed, 126 insertions(+), 15 deletions(-)
> >
> > diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h
> > index 54cbf07fb4e9..5acd99d08e74 100644
> > --- a/arch/riscv/include/asm/fixmap.h
> > +++ b/arch/riscv/include/asm/fixmap.h
> > @@ -43,7 +43,7 @@ enum fixed_addresses {
> >       __end_of_fixed_addresses
> >  };
> >
> > -#define FIXMAP_PAGE_IO               PAGE_KERNEL
> > +#define FIXMAP_PAGE_IO               PAGE_IOREMAP
> >
> >  #define __early_set_fixmap   __set_fixmap
> >
> > diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h
> > index 228261aa9628..16d251282b1d 100644
> > --- a/arch/riscv/include/asm/pgtable-64.h
> > +++ b/arch/riscv/include/asm/pgtable-64.h
> > @@ -59,14 +59,29 @@ static inline void pud_clear(pud_t *pudp)
> >       set_pud(pudp, __pud(0));
> >  }
> >
> > +static inline unsigned long _chg_of_pmd(pmd_t pmd)
> > +{
> > +     return (pmd_val(pmd) & _PAGE_CHG_MASK);
> > +}
> > +
> > +static inline unsigned long _chg_of_pud(pud_t pud)
> > +{
> > +     return (pud_val(pud) & _PAGE_CHG_MASK);
> > +}
> > +
> > +static inline unsigned long _chg_of_pte(pte_t pte)
> > +{
> > +     return (pte_val(pte) & _PAGE_CHG_MASK);
> > +}
> > +
> >  static inline pmd_t *pud_pgtable(pud_t pud)
> >  {
> > -     return (pmd_t *)pfn_to_virt(pud_val(pud) >> _PAGE_PFN_SHIFT);
> > +     return (pmd_t *)pfn_to_virt(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT);
> >  }
> >
> >  static inline struct page *pud_page(pud_t pud)
> >  {
> > -     return pfn_to_page(pud_val(pud) >> _PAGE_PFN_SHIFT);
> > +     return pfn_to_page(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT);
> >  }
> >
> >  static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot)
> > @@ -76,7 +91,7 @@ static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot)
> >
> >  static inline unsigned long _pmd_pfn(pmd_t pmd)
> >  {
> > -     return pmd_val(pmd) >> _PAGE_PFN_SHIFT;
> > +     return _chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT;
> >  }
> >
> >  #define mk_pmd(page, prot)    pfn_pmd(page_to_pfn(page), prot)
> > diff --git a/arch/riscv/include/asm/pgtable-bits.h b/arch/riscv/include/asm/pgtable-bits.h
> > index 2ee413912926..e5b0fce4ddc5 100644
> > --- a/arch/riscv/include/asm/pgtable-bits.h
> > +++ b/arch/riscv/include/asm/pgtable-bits.h
> > @@ -7,7 +7,7 @@
> >  #define _ASM_RISCV_PGTABLE_BITS_H
> >
> >  /*
> > - * PTE format:
> > + * rv32 PTE format:
> >   * | XLEN-1  10 | 9             8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
> >   *       PFN      reserved for SW   D   A   G   U   X   W   R   V
> >   */
> > @@ -24,6 +24,40 @@
> >  #define _PAGE_DIRTY     (1 << 7)    /* Set by hardware on any write */
> >  #define _PAGE_SOFT      (1 << 8)    /* Reserved for software */
> >
> > +#if !defined(__ASSEMBLY__) && defined(CONFIG_64BIT)
> > +/*
> > + * rv64 PTE format:
> > + * | 63 | 62 61 | 60 54 | 53  10 | 9             8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
> > + *   N      MT     RSV    PFN      reserved for SW   D   A   G   U   X   W   R   V
> > + * [62:61] Memory Type definitions:
> > + *  00 - PMA    Normal Cacheable, No change to implied PMA memory type
> > + *  01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
> > + *  10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
> > + *  11 - Rsvd   Reserved for future standard use
> > + */
> > +#define _SVPBMT_PMA          0UL
> > +#define _SVPBMT_NC           (1UL << 61)
> > +#define _SVPBMT_IO           (1UL << 62)
> > +#define _SVPBMT_MASK         (_SVPBMT_NC | _SVPBMT_IO)
> > +
> > +extern struct __svpbmt_struct {
> > +     unsigned long mask;
> > +     unsigned long pma;
> > +     unsigned long nocache;
> > +     unsigned long io;
> > +} __svpbmt __cacheline_aligned;
> > +
> > +#define _PAGE_MASK           __svpbmt.mask
> > +#define _PAGE_PMA            __svpbmt.pma
> > +#define _PAGE_NOCACHE                __svpbmt.nocache
> > +#define _PAGE_IO             __svpbmt.io
> > +#else
> > +#define _PAGE_MASK           0
> > +#define _PAGE_PMA            0
> > +#define _PAGE_NOCACHE                0
> > +#define _PAGE_IO             0
> > +#endif /* !__ASSEMBLY__ && CONFIG_64BIT */
> > +
> >  #define _PAGE_SPECIAL   _PAGE_SOFT
> >  #define _PAGE_TABLE     _PAGE_PRESENT
> >
> > @@ -38,7 +72,8 @@
> >  /* Set of bits to preserve across pte_modify() */
> >  #define _PAGE_CHG_MASK  (~(unsigned long)(_PAGE_PRESENT | _PAGE_READ |       \
> >                                         _PAGE_WRITE | _PAGE_EXEC |    \
> > -                                       _PAGE_USER | _PAGE_GLOBAL))
> > +                                       _PAGE_USER | _PAGE_GLOBAL |   \
> > +                                       _PAGE_MASK))
> >  /*
> >   * when all of R/W/X are zero, the PTE is a pointer to the next level
> >   * of the page table; otherwise, it is a leaf PTE.
> > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
> > index bf204e7c1f74..0f7a6541015f 100644
> > --- a/arch/riscv/include/asm/pgtable.h
> > +++ b/arch/riscv/include/asm/pgtable.h
> > @@ -138,7 +138,8 @@
> >                               | _PAGE_PRESENT \
> >                               | _PAGE_ACCESSED \
> >                               | _PAGE_DIRTY \
> > -                             | _PAGE_GLOBAL)
> > +                             | _PAGE_GLOBAL \
> > +                             | _PAGE_PMA)
> >
> >  #define PAGE_KERNEL          __pgprot(_PAGE_KERNEL)
> >  #define PAGE_KERNEL_READ     __pgprot(_PAGE_KERNEL & ~_PAGE_WRITE)
> > @@ -148,11 +149,9 @@
> >
> >  #define PAGE_TABLE           __pgprot(_PAGE_TABLE)
> >
> > -/*
> > - * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't
> > - * change the properties of memory regions.
> > - */
> > -#define _PAGE_IOREMAP _PAGE_KERNEL
> > +#define _PAGE_IOREMAP        ((_PAGE_KERNEL & ~_PAGE_MASK) | _PAGE_IO)
> > +
> > +#define PAGE_IOREMAP         __pgprot(_PAGE_IOREMAP)
> >
> >  extern pgd_t swapper_pg_dir[];
> >
> > @@ -232,12 +231,12 @@ static inline unsigned long _pgd_pfn(pgd_t pgd)
> >
> >  static inline struct page *pmd_page(pmd_t pmd)
> >  {
> > -     return pfn_to_page(pmd_val(pmd) >> _PAGE_PFN_SHIFT);
> > +     return pfn_to_page(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT);
> >  }
> >
> >  static inline unsigned long pmd_page_vaddr(pmd_t pmd)
> >  {
> > -     return (unsigned long)pfn_to_virt(pmd_val(pmd) >> _PAGE_PFN_SHIFT);
> > +     return (unsigned long)pfn_to_virt(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT);
> >  }
> >
> >  static inline pte_t pmd_pte(pmd_t pmd)
> > @@ -253,7 +252,7 @@ static inline pte_t pud_pte(pud_t pud)
> >  /* Yields the page frame number (PFN) of a page table entry */
> >  static inline unsigned long pte_pfn(pte_t pte)
> >  {
> > -     return (pte_val(pte) >> _PAGE_PFN_SHIFT);
> > +     return (_chg_of_pte(pte) >> _PAGE_PFN_SHIFT);
> >  }
> >
> >  #define pte_page(x)     pfn_to_page(pte_pfn(x))
> > @@ -492,6 +491,28 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma,
> >       return ptep_test_and_clear_young(vma, address, ptep);
> >  }
> >
> > +#define pgprot_noncached pgprot_noncached
> > +static inline pgprot_t pgprot_noncached(pgprot_t _prot)
> > +{
> > +     unsigned long prot = pgprot_val(_prot);
> > +
> > +     prot &= ~_PAGE_MASK;
> > +     prot |= _PAGE_IO;
> > +
> > +     return __pgprot(prot);
> > +}
> > +
> > +#define pgprot_writecombine pgprot_writecombine
> > +static inline pgprot_t pgprot_writecombine(pgprot_t _prot)
> > +{
> > +     unsigned long prot = pgprot_val(_prot);
> > +
> > +     prot &= ~_PAGE_MASK;
> > +     prot |= _PAGE_NOCACHE;
> > +
> > +     return __pgprot(prot);
> > +}
> > +
> >  /*
> >   * THP functions
> >   */
> > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> > index d959d207a40d..fa7480cb8b87 100644
> > --- a/arch/riscv/kernel/cpufeature.c
> > +++ b/arch/riscv/kernel/cpufeature.c
> > @@ -8,6 +8,7 @@
> >
> >  #include <linux/bitmap.h>
> >  #include <linux/of.h>
> > +#include <linux/pgtable.h>
> >  #include <asm/processor.h>
> >  #include <asm/hwcap.h>
> >  #include <asm/smp.h>
> > @@ -59,6 +60,38 @@ bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit)
> >  }
> >  EXPORT_SYMBOL_GPL(__riscv_isa_extension_available);
> >
> > +static void __init mmu_supports_svpbmt(void)
> > +{
> > +#if defined(CONFIG_MMU) && defined(CONFIG_64BIT)
> > +     struct device_node *node;
> > +     const char *str;
> > +
> > +     for_each_of_cpu_node(node) {
> > +             if (of_property_read_string(node, "mmu-type", &str))
> > +                     continue;
> > +
> > +             if (!strncmp(str + 6, "none", 4))
> > +                     continue;
> > +
> > +             if (of_property_read_string(node, "mmu", &str))
> > +                     continue;
> > +
> > +             if (strncmp(str + 6, "svpmbt", 6))
>
> same here ... check for "svpbmt" [m seems to be at the wrong position]
>
>
> > +                     continue;
> > +     }
> > +
> > +     __svpbmt.pma            = _SVPBMT_PMA;
> > +     __svpbmt.nocache        = _SVPBMT_NC;
> > +     __svpbmt.io             = _SVPBMT_IO;
> > +     __svpbmt.mask           = _SVPBMT_MASK;
> > +#endif
> > +}
> > +
> > +static void __init mmu_supports(void)
> > +{
> > +     mmu_supports_svpbmt();
> > +}
> > +
> >  void __init riscv_fill_hwcap(void)
> >  {
> >       struct device_node *node;
> > @@ -67,6 +100,8 @@ void __init riscv_fill_hwcap(void)
> >       size_t i, j, isa_len;
> >       static unsigned long isa2hwcap[256] = {0};
> >
> > +     mmu_supports();
> > +
> >       isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I;
> >       isa2hwcap['m'] = isa2hwcap['M'] = COMPAT_HWCAP_ISA_M;
> >       isa2hwcap['a'] = isa2hwcap['A'] = COMPAT_HWCAP_ISA_A;
> > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> > index 24b2b8044602..e4e658165ee1 100644
> > --- a/arch/riscv/mm/init.c
> > +++ b/arch/riscv/mm/init.c
> > @@ -854,3 +854,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
> >       return vmemmap_populate_basepages(start, end, node, NULL);
> >  }
> >  #endif
> > +
> > +#if defined(CONFIG_64BIT)
> > +struct __svpbmt_struct __svpbmt __ro_after_init;
> > +EXPORT_SYMBOL(__svpbmt);
> > +#endif
> >
>
>
>
>

Re: [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports

[Wei Fu]

Thanks for reminding me, Guo Ren. :-)
yes, I am working on the new version , yes, my bad, I am adding it in to my V5

On Tue, Nov 30, 2021 at 6:19 PM Guo Ren <guoren@kernel.org> wrote:
>
> Hi,
>
> We forgot fixmap, add below into your patch.
>
> diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h
> index 54cbf07fb4e9..899b59bdb9eb 100644
> --- a/arch/riscv/include/asm/fixmap.h
> +++ b/arch/riscv/include/asm/fixmap.h
> @@ -43,8 +43,6 @@ enum fixed_addresses {
>         __end_of_fixed_addresses
>  };
>
> -#define FIXMAP_PAGE_IO         PAGE_KERNEL
> -
>  #define __early_set_fixmap     __set_fixmap
>
>  #define __late_set_fixmap      __set_fixmap
> diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
> index f3c9f9a1c1bb..9bb06384c57f 100644
> --- a/arch/riscv/include/asm/pgtable.h
> +++ b/arch/riscv/include/asm/pgtable.h
> @@ -126,6 +126,8 @@
>                                 | _PAGE_SHARE \
>                                 | _PAGE_SO)
>
> +#define PAGE_KERNEL_IO         __pgprot(_PAGE_IOREMAP)
>
> On Mon, Nov 29, 2021 at 9:41 AM <wefu@redhat.com> wrote:
> >
> > From: Wei Fu <wefu@redhat.com>
> >
> > This patch follows the standard pure RISC-V Svpbmt extension in
> > privilege spec to solve the non-coherent SOC dma synchronization
> > issues.
> >
> > Here is the svpbmt PTE format:
> > | 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
> >   N     MT     RSW    D   A   G   U   X   W   R   V
> >         ^
> >
> > Of the Reserved bits [63:54] in a leaf PTE, the high bit is already
> > allocated (as the N bit), so bits [62:61] are used as the MT (aka
> > MemType) field. This field specifies one of three memory types that
> > are close equivalents (or equivalent in effect) to the three main x86
> > and ARMv8 memory types - as shown in the following table.
> >
> > RISC-V
> > Encoding &
> > MemType     RISC-V Description
> > ----------  ------------------------------------------------
> > 00 - PMA    Normal Cacheable, No change to implied PMA memory type
> > 01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
> > 10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
> > 11 - Rsvd   Reserved for future standard use
> >
> > The standard protection_map[] needn't be modified because the "PMA"
> > type keeps the highest bits zero. And the whole modification is
> > limited in the arch/riscv/* and using a global variable
> > (__svpbmt) as _PAGE_MASK/IO/NOCACHE for pgprot_noncached
> > (&writecombine) in pgtable.h. We also add _PAGE_CHG_MASK to filter
> > PFN than before.
> >
> > Enable it in devicetree - (Add "riscv,svpbmt" in the mmu of cpu node)
> >  - mmu:
> >      riscv,svpmbt
> >
> > Signed-off-by: Wei Fu <wefu@redhat.com>
> > Co-developed-by: Liu Shaohua <liush@allwinnertech.com>
> > Signed-off-by: Liu Shaohua <liush@allwinnertech.com>
> > Co-developed-by: Guo Ren <guoren@kernel.org>
> > Signed-off-by: Guo Ren <guoren@kernel.org>
> > Cc: Palmer Dabbelt <palmerdabbelt@google.com>
> > Cc: Christoph Hellwig <hch@lst.de>
> > Cc: Anup Patel <anup.patel@wdc.com>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Atish Patra <atish.patra@wdc.com>
> > Cc: Drew Fustini <drew@beagleboard.org>
> > Cc: Wei Fu <wefu@redhat.com>
> > Cc: Wei Wu <lazyparser@gmail.com>
> > Cc: Chen-Yu Tsai <wens@csie.org>
> > Cc: Maxime Ripard <maxime@cerno.tech>
> > Cc: Daniel Lustig <dlustig@nvidia.com>
> > Cc: Greg Favor <gfavor@ventanamicro.com>
> > Cc: Andrea Mondelli <andrea.mondelli@huawei.com>
> > Cc: Jonathan Behrens <behrensj@mit.edu>
> > Cc: Xinhaoqu (Freddie) <xinhaoqu@huawei.com>
> > Cc: Bill Huffman <huffman@cadence.com>
> > Cc: Nick Kossifidis <mick@ics.forth.gr>
> > Cc: Allen Baum <allen.baum@esperantotech.com>
> > Cc: Josh Scheid <jscheid@ventanamicro.com>
> > Cc: Richard Trauben <rtrauben@gmail.com>
> > ---
> >  arch/riscv/include/asm/fixmap.h       |  2 +-
> >  arch/riscv/include/asm/pgtable-64.h   | 21 ++++++++++++---
> >  arch/riscv/include/asm/pgtable-bits.h | 39 +++++++++++++++++++++++++--
> >  arch/riscv/include/asm/pgtable.h      | 39 ++++++++++++++++++++-------
> >  arch/riscv/kernel/cpufeature.c        | 35 ++++++++++++++++++++++++
> >  arch/riscv/mm/init.c                  |  5 ++++
> >  6 files changed, 126 insertions(+), 15 deletions(-)
> >
> > diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h
> > index 54cbf07fb4e9..5acd99d08e74 100644
> > --- a/arch/riscv/include/asm/fixmap.h
> > +++ b/arch/riscv/include/asm/fixmap.h
> > @@ -43,7 +43,7 @@ enum fixed_addresses {
> >         __end_of_fixed_addresses
> >  };
> >
> > -#define FIXMAP_PAGE_IO         PAGE_KERNEL
> > +#define FIXMAP_PAGE_IO         PAGE_IOREMAP
> >
> >  #define __early_set_fixmap     __set_fixmap
> >
> > diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h
> > index 228261aa9628..16d251282b1d 100644
> > --- a/arch/riscv/include/asm/pgtable-64.h
> > +++ b/arch/riscv/include/asm/pgtable-64.h
> > @@ -59,14 +59,29 @@ static inline void pud_clear(pud_t *pudp)
> >         set_pud(pudp, __pud(0));
> >  }
> >
> > +static inline unsigned long _chg_of_pmd(pmd_t pmd)
> > +{
> > +       return (pmd_val(pmd) & _PAGE_CHG_MASK);
> > +}
> > +
> > +static inline unsigned long _chg_of_pud(pud_t pud)
> > +{
> > +       return (pud_val(pud) & _PAGE_CHG_MASK);
> > +}
> > +
> > +static inline unsigned long _chg_of_pte(pte_t pte)
> > +{
> > +       return (pte_val(pte) & _PAGE_CHG_MASK);
> > +}
> > +
> >  static inline pmd_t *pud_pgtable(pud_t pud)
> >  {
> > -       return (pmd_t *)pfn_to_virt(pud_val(pud) >> _PAGE_PFN_SHIFT);
> > +       return (pmd_t *)pfn_to_virt(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT);
> >  }
> >
> >  static inline struct page *pud_page(pud_t pud)
> >  {
> > -       return pfn_to_page(pud_val(pud) >> _PAGE_PFN_SHIFT);
> > +       return pfn_to_page(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT);
> >  }
> >
> >  static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot)
> > @@ -76,7 +91,7 @@ static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot)
> >
> >  static inline unsigned long _pmd_pfn(pmd_t pmd)
> >  {
> > -       return pmd_val(pmd) >> _PAGE_PFN_SHIFT;
> > +       return _chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT;
> >  }
> >
> >  #define mk_pmd(page, prot)    pfn_pmd(page_to_pfn(page), prot)
> > diff --git a/arch/riscv/include/asm/pgtable-bits.h b/arch/riscv/include/asm/pgtable-bits.h
> > index 2ee413912926..e5b0fce4ddc5 100644
> > --- a/arch/riscv/include/asm/pgtable-bits.h
> > +++ b/arch/riscv/include/asm/pgtable-bits.h
> > @@ -7,7 +7,7 @@
> >  #define _ASM_RISCV_PGTABLE_BITS_H
> >
> >  /*
> > - * PTE format:
> > + * rv32 PTE format:
> >   * | XLEN-1  10 | 9             8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
> >   *       PFN      reserved for SW   D   A   G   U   X   W   R   V
> >   */
> > @@ -24,6 +24,40 @@
> >  #define _PAGE_DIRTY     (1 << 7)    /* Set by hardware on any write */
> >  #define _PAGE_SOFT      (1 << 8)    /* Reserved for software */
> >
> > +#if !defined(__ASSEMBLY__) && defined(CONFIG_64BIT)
> > +/*
> > + * rv64 PTE format:
> > + * | 63 | 62 61 | 60 54 | 53  10 | 9             8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
> > + *   N      MT     RSV    PFN      reserved for SW   D   A   G   U   X   W   R   V
> > + * [62:61] Memory Type definitions:
> > + *  00 - PMA    Normal Cacheable, No change to implied PMA memory type
> > + *  01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
> > + *  10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
> > + *  11 - Rsvd   Reserved for future standard use
> > + */
> > +#define _SVPBMT_PMA            0UL
> > +#define _SVPBMT_NC             (1UL << 61)
> > +#define _SVPBMT_IO             (1UL << 62)
> > +#define _SVPBMT_MASK           (_SVPBMT_NC | _SVPBMT_IO)
> > +
> > +extern struct __svpbmt_struct {
> > +       unsigned long mask;
> > +       unsigned long pma;
> > +       unsigned long nocache;
> > +       unsigned long io;
> > +} __svpbmt __cacheline_aligned;
> > +
> > +#define _PAGE_MASK             __svpbmt.mask
> > +#define _PAGE_PMA              __svpbmt.pma
> > +#define _PAGE_NOCACHE          __svpbmt.nocache
> > +#define _PAGE_IO               __svpbmt.io
> > +#else
> > +#define _PAGE_MASK             0
> > +#define _PAGE_PMA              0
> > +#define _PAGE_NOCACHE          0
> > +#define _PAGE_IO               0
> > +#endif /* !__ASSEMBLY__ && CONFIG_64BIT */
> > +
> >  #define _PAGE_SPECIAL   _PAGE_SOFT
> >  #define _PAGE_TABLE     _PAGE_PRESENT
> >
> > @@ -38,7 +72,8 @@
> >  /* Set of bits to preserve across pte_modify() */
> >  #define _PAGE_CHG_MASK  (~(unsigned long)(_PAGE_PRESENT | _PAGE_READ | \
> >                                           _PAGE_WRITE | _PAGE_EXEC |    \
> > -                                         _PAGE_USER | _PAGE_GLOBAL))
> > +                                         _PAGE_USER | _PAGE_GLOBAL |   \
> > +                                         _PAGE_MASK))
> >  /*
> >   * when all of R/W/X are zero, the PTE is a pointer to the next level
> >   * of the page table; otherwise, it is a leaf PTE.
> > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
> > index bf204e7c1f74..0f7a6541015f 100644
> > --- a/arch/riscv/include/asm/pgtable.h
> > +++ b/arch/riscv/include/asm/pgtable.h
> > @@ -138,7 +138,8 @@
> >                                 | _PAGE_PRESENT \
> >                                 | _PAGE_ACCESSED \
> >                                 | _PAGE_DIRTY \
> > -                               | _PAGE_GLOBAL)
> > +                               | _PAGE_GLOBAL \
> > +                               | _PAGE_PMA)
> >
> >  #define PAGE_KERNEL            __pgprot(_PAGE_KERNEL)
> >  #define PAGE_KERNEL_READ       __pgprot(_PAGE_KERNEL & ~_PAGE_WRITE)
> > @@ -148,11 +149,9 @@
> >
> >  #define PAGE_TABLE             __pgprot(_PAGE_TABLE)
> >
> > -/*
> > - * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't
> > - * change the properties of memory regions.
> > - */
> > -#define _PAGE_IOREMAP _PAGE_KERNEL
> > +#define _PAGE_IOREMAP  ((_PAGE_KERNEL & ~_PAGE_MASK) | _PAGE_IO)
> > +
> > +#define PAGE_IOREMAP           __pgprot(_PAGE_IOREMAP)
> >
> >  extern pgd_t swapper_pg_dir[];
> >
> > @@ -232,12 +231,12 @@ static inline unsigned long _pgd_pfn(pgd_t pgd)
> >
> >  static inline struct page *pmd_page(pmd_t pmd)
> >  {
> > -       return pfn_to_page(pmd_val(pmd) >> _PAGE_PFN_SHIFT);
> > +       return pfn_to_page(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT);
> >  }
> >
> >  static inline unsigned long pmd_page_vaddr(pmd_t pmd)
> >  {
> > -       return (unsigned long)pfn_to_virt(pmd_val(pmd) >> _PAGE_PFN_SHIFT);
> > +       return (unsigned long)pfn_to_virt(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT);
> >  }
> >
> >  static inline pte_t pmd_pte(pmd_t pmd)
> > @@ -253,7 +252,7 @@ static inline pte_t pud_pte(pud_t pud)
> >  /* Yields the page frame number (PFN) of a page table entry */
> >  static inline unsigned long pte_pfn(pte_t pte)
> >  {
> > -       return (pte_val(pte) >> _PAGE_PFN_SHIFT);
> > +       return (_chg_of_pte(pte) >> _PAGE_PFN_SHIFT);
> >  }
> >
> >  #define pte_page(x)     pfn_to_page(pte_pfn(x))
> > @@ -492,6 +491,28 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma,
> >         return ptep_test_and_clear_young(vma, address, ptep);
> >  }
> >
> > +#define pgprot_noncached pgprot_noncached
> > +static inline pgprot_t pgprot_noncached(pgprot_t _prot)
> > +{
> > +       unsigned long prot = pgprot_val(_prot);
> > +
> > +       prot &= ~_PAGE_MASK;
> > +       prot |= _PAGE_IO;
> > +
> > +       return __pgprot(prot);
> > +}
> > +
> > +#define pgprot_writecombine pgprot_writecombine
> > +static inline pgprot_t pgprot_writecombine(pgprot_t _prot)
> > +{
> > +       unsigned long prot = pgprot_val(_prot);
> > +
> > +       prot &= ~_PAGE_MASK;
> > +       prot |= _PAGE_NOCACHE;
> > +
> > +       return __pgprot(prot);
> > +}
> > +
> >  /*
> >   * THP functions
> >   */
> > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> > index d959d207a40d..fa7480cb8b87 100644
> > --- a/arch/riscv/kernel/cpufeature.c
> > +++ b/arch/riscv/kernel/cpufeature.c
> > @@ -8,6 +8,7 @@
> >
> >  #include <linux/bitmap.h>
> >  #include <linux/of.h>
> > +#include <linux/pgtable.h>
> >  #include <asm/processor.h>
> >  #include <asm/hwcap.h>
> >  #include <asm/smp.h>
> > @@ -59,6 +60,38 @@ bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit)
> >  }
> >  EXPORT_SYMBOL_GPL(__riscv_isa_extension_available);
> >
> > +static void __init mmu_supports_svpbmt(void)
> > +{
> > +#if defined(CONFIG_MMU) && defined(CONFIG_64BIT)
> > +       struct device_node *node;
> > +       const char *str;
> > +
> > +       for_each_of_cpu_node(node) {
> > +               if (of_property_read_string(node, "mmu-type", &str))
> > +                       continue;
> > +
> > +               if (!strncmp(str + 6, "none", 4))
> > +                       continue;
> > +
> > +               if (of_property_read_string(node, "mmu", &str))
> > +                       continue;
> > +
> > +               if (strncmp(str + 6, "svpmbt", 6))
> > +                       continue;
> > +       }
> > +
> > +       __svpbmt.pma            = _SVPBMT_PMA;
> > +       __svpbmt.nocache        = _SVPBMT_NC;
> > +       __svpbmt.io             = _SVPBMT_IO;
> > +       __svpbmt.mask           = _SVPBMT_MASK;
> > +#endif
> > +}
> > +
> > +static void __init mmu_supports(void)
> > +{
> > +       mmu_supports_svpbmt();
> > +}
> > +
> >  void __init riscv_fill_hwcap(void)
> >  {
> >         struct device_node *node;
> > @@ -67,6 +100,8 @@ void __init riscv_fill_hwcap(void)
> >         size_t i, j, isa_len;
> >         static unsigned long isa2hwcap[256] = {0};
> >
> > +       mmu_supports();
> > +
> >         isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I;
> >         isa2hwcap['m'] = isa2hwcap['M'] = COMPAT_HWCAP_ISA_M;
> >         isa2hwcap['a'] = isa2hwcap['A'] = COMPAT_HWCAP_ISA_A;
> > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> > index 24b2b8044602..e4e658165ee1 100644
> > --- a/arch/riscv/mm/init.c
> > +++ b/arch/riscv/mm/init.c
> > @@ -854,3 +854,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
> >         return vmemmap_populate_basepages(start, end, node, NULL);
> >  }
> >  #endif
> > +
> > +#if defined(CONFIG_64BIT)
> > +struct __svpbmt_struct __svpbmt __ro_after_init;
> > +EXPORT_SYMBOL(__svpbmt);
> > +#endif
> > --
> > 2.25.4
> >
>
>
> --
> Best Regards
>  Guo Ren
>
> ML: https://lore.kernel.org/linux-csky/
>

Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt

[Tsukasa OI]

On 2021/12/01 10:21, Atish Patra wrote:
> On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <jrtc27@jrtc27.com> wrote:
>>
>> On 30 Nov 2021, at 15:01, Philipp Tomsich <philipp.tomsich@vrull.eu> wrote:
>>>
>>> We did touch on this in our coordination call a few weeks ago: the
>>> grouping under mmu and the bool-entries were chosen because of their
>>> similarity to other extensions (i.e. for Zb[abcs] there could/should
>>> be a bool-entry under each cpu-node — for some Zv* entries a subnode
>>> might be needed with further parameters).
>>>
>>> The string-based approach (as in the originally proposed "mmu-type=")
>>> would like not scale with the proliferation of small & modular
>>> extensions.
>>
>> I don’t see why the Sv* extensions need to be under an mmu node then,
>> unless the intent is that every extension be grouped under a sub-node
>> (which doesn’t seem viable due to extensions like Zbk*, unless you
>> group by Ss, Sv and Z)?
>>
> 
> It shouldn't be. All the ISA extensions (i.e. standard, supervisor & hypervisor)
> with prefix S,Z,H should be kept separate in a separate node for easy
> parsing.

"Easy parsing" is not quite convincing.

There's a reason other than that I made RFC PATCH to parse
multi-letter extensions:

v1: <http://lists.infradead.org/pipermail/linux-riscv/2021-November/010252.html>
v2: <http://lists.infradead.org/pipermail/linux-riscv/2021-November/010350.html>

(note: those patches will break RISC-V KVM because of possible ISA
       Manual inconsistency and discussion/resolution needed)

(...continued below...)

> 
> "riscv,isa" dt property will not scale at all. Just look at the few
> extensions that were ratified this year
> and Linux kernel needs to support them.
> 
> "Sscofpmf", "Svpbmt", "Zicbom"
> 
>> Also, what is going to happen to the current riscv,isa? Will that
>> continue to exist and duplicate the info, or will kernels be required
>> to reconstruct the string themselves if they want to display it to
>> users?
>>
> 
> This is my personal preference:
> riscv,isa will continue to base Standard ISA extensions that have
> single letter extensions.
> 
> This new DT node will encode all the non-single letter extensions.
> I am not sure if it should include some provisions for custom
> extensions starting with X because
> that will be platform specific.
> 
> Again, this is just my personal preference. I will try to send a patch
> soon so that we can initiate a broader
> discussion of the scheme and agree/disagree on something.

For supervisor-only extensions like "Svpbmt", new DT node would be a
reasonable solution (and I would not directly object about that node).

However, there's many multi-letter extensions that are useful for
user mode.  Because "riscv,isa" is exposed via sysfs and procfs
(/proc/cpuinfo), it can be really helpful to have multi-letter
extensions.  Also, current version of Spike, a RISC-V ISA Simulator
puts all multi-letter extensions in "riscv,isa" and I thought this is
intended.

My preference:
(1) Allow having multi-letter extensions and versions in "riscv,isa"
(2) Adding new DT node for supervisor-related extensions would be
    reasonable (but I don't strongly agree/disagree).

Thanks,
Tsukasa

> 
> 
> 
>> As a FreeBSD developer I’m obviously not a part of many of these
>> discussions, but what the Linux community imposes as the device tree
>> bindings has a real impact on us.
>>
>> Jess
>>
>>> On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com> wrote:
>>>>
>>>> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke:
>>>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote:
>>>>>>>
>>>>>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner:
>>>>>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt:
>>>>>>>>> On 11/29/21 02:40, wefu@redhat.com wrote:
>>>>>>>>>> From: Wei Fu <wefu@redhat.com>
>>>>>>>>>>
>>>>>>>>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt"
>>>>>>>>>> in the DT mmu node. Update dt-bindings related property here.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Wei Fu <wefu@redhat.com>
>>>>>>>>>> Co-developed-by: Guo Ren <guoren@kernel.org>
>>>>>>>>>> Signed-off-by: Guo Ren <guoren@kernel.org>
>>>>>>>>>> Cc: Anup Patel <anup@brainfault.org>
>>>>>>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com>
>>>>>>>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>>>>>>>> ---
>>>>>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++
>>>>>>>>>> 1 file changed, 10 insertions(+)
>>>>>>>>>>
>>>>>>>>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
>>>>>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644
>>>>>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
>>>>>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
>>>>>>>>>> @@ -63,6 +63,16 @@ properties:
>>>>>>>>>>      - riscv,sv48
>>>>>>>>>>      - riscv,none
>>>>>>>>>>
>>>>>>>>>> +  mmu:
>>>>>>>>>
>>>>>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before
>>>>>>>>> mmu-type?
>>>>>>>>>
>>>>>>>>>> +    description:
>>>>>>>>>> +      Describes the CPU's MMU Standard Extensions support.
>>>>>>>>>> +      These values originate from the RISC-V Privileged
>>>>>>>>>> +      Specification document, available from
>>>>>>>>>> +      https://riscv.org/specifications/
>>>>>>>>>> +    $ref: '/schemas/types.yaml#/definitions/string'
>>>>>>>>>> +    enum:
>>>>>>>>>> +      - riscv,svpmbt
>>>>>>>>>
>>>>>>>>> The privileged specification has multiple MMU related extensions:
>>>>>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum?
>>>>>>>>
>>>>>>>> I remember in some earlier version some way back there was the
>>>>>>>> suggestion of using a sub-node instead and then adding boolean
>>>>>>>> properties for the supported extensions.
>>>>>>>>
>>>>>>>> Aka something like
>>>>>>>>   mmu {
>>>>>>>>           riscv,svpbmt;
>>>>>>>>   };
>>>>>>>
>>>>>>> For the record, I'm talking about the mail from september
>>>>>>> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/
>>>>>>>
>>>>>>> So having a sub-node would make adding future extensions
>>>>>>> way nicer.
>>>>>>
>>>>>> Svpbmt is just an ISA extension, and should be treated like any other.
>>>>>> Let’s not invent two different ways of representing that in the device
>>>>>> tree.
>>>>>
>>>>> Heinrich asked how the other extensions should be handled
>>>>> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with these?
>>>>
>>>> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may not be
>>>> a concrete plan for that yet, but that means you should speak with the
>>>> people involved with such extensions and come up with something
>>>> appropriate together.
>>>>
>>>> Jess
>>>>
>>
>>
>> _______________________________________________
>> linux-riscv mailing list
>> linux-riscv@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv
> 
> 
> 
> --
> Regards,
> Atish
> 
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
> 

Re: [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports

[Wei Fu]

Hi, Jisheng Zhang,

On Mon, Nov 29, 2021 at 9:44 PM Jisheng Zhang <jszhang@kernel.org> wrote:
>
> On Mon, 29 Nov 2021 09:40:07 +0800
> wefu@redhat.com wrote:
>
> > From: Wei Fu <wefu@redhat.com>
> >
> > This patch follows the standard pure RISC-V Svpbmt extension in
> > privilege spec to solve the non-coherent SOC dma synchronization
> > issues.
> >
> > Here is the svpbmt PTE format:
> > | 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
> >   N     MT     RSW    D   A   G   U   X   W   R   V
> >         ^
> >
> > Of the Reserved bits [63:54] in a leaf PTE, the high bit is already
> > allocated (as the N bit), so bits [62:61] are used as the MT (aka
> > MemType) field. This field specifies one of three memory types that
> > are close equivalents (or equivalent in effect) to the three main x86
> > and ARMv8 memory types - as shown in the following table.
> >
> > RISC-V
> > Encoding &
> > MemType     RISC-V Description
> > ----------  ------------------------------------------------
> > 00 - PMA    Normal Cacheable, No change to implied PMA memory type
> > 01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
> > 10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
> > 11 - Rsvd   Reserved for future standard use
> >
> > The standard protection_map[] needn't be modified because the "PMA"
> > type keeps the highest bits zero. And the whole modification is
> > limited in the arch/riscv/* and using a global variable
> > (__svpbmt) as _PAGE_MASK/IO/NOCACHE for pgprot_noncached
> > (&writecombine) in pgtable.h. We also add _PAGE_CHG_MASK to filter
> > PFN than before.
> >
> > Enable it in devicetree - (Add "riscv,svpbmt" in the mmu of cpu node)
> >  - mmu:
> >      riscv,svpmbt
> >
> > Signed-off-by: Wei Fu <wefu@redhat.com>
> > Co-developed-by: Liu Shaohua <liush@allwinnertech.com>
> > Signed-off-by: Liu Shaohua <liush@allwinnertech.com>
> > Co-developed-by: Guo Ren <guoren@kernel.org>
> > Signed-off-by: Guo Ren <guoren@kernel.org>
> > Cc: Palmer Dabbelt <palmerdabbelt@google.com>
> > Cc: Christoph Hellwig <hch@lst.de>
> > Cc: Anup Patel <anup.patel@wdc.com>
> > Cc: Arnd Bergmann <arnd@arndb.de>
> > Cc: Atish Patra <atish.patra@wdc.com>
> > Cc: Drew Fustini <drew@beagleboard.org>
> > Cc: Wei Fu <wefu@redhat.com>
> > Cc: Wei Wu <lazyparser@gmail.com>
> > Cc: Chen-Yu Tsai <wens@csie.org>
> > Cc: Maxime Ripard <maxime@cerno.tech>
> > Cc: Daniel Lustig <dlustig@nvidia.com>
> > Cc: Greg Favor <gfavor@ventanamicro.com>
> > Cc: Andrea Mondelli <andrea.mondelli@huawei.com>
> > Cc: Jonathan Behrens <behrensj@mit.edu>
> > Cc: Xinhaoqu (Freddie) <xinhaoqu@huawei.com>
> > Cc: Bill Huffman <huffman@cadence.com>
> > Cc: Nick Kossifidis <mick@ics.forth.gr>
> > Cc: Allen Baum <allen.baum@esperantotech.com>
> > Cc: Josh Scheid <jscheid@ventanamicro.com>
> > Cc: Richard Trauben <rtrauben@gmail.com>
> > ---
> >  arch/riscv/include/asm/fixmap.h       |  2 +-
> >  arch/riscv/include/asm/pgtable-64.h   | 21 ++++++++++++---
> >  arch/riscv/include/asm/pgtable-bits.h | 39 +++++++++++++++++++++++++--
> >  arch/riscv/include/asm/pgtable.h      | 39 ++++++++++++++++++++-------
> >  arch/riscv/kernel/cpufeature.c        | 35 ++++++++++++++++++++++++
> >  arch/riscv/mm/init.c                  |  5 ++++
> >  6 files changed, 126 insertions(+), 15 deletions(-)
> >
> > diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h
> > index 54cbf07fb4e9..5acd99d08e74 100644
> > --- a/arch/riscv/include/asm/fixmap.h
> > +++ b/arch/riscv/include/asm/fixmap.h
> > @@ -43,7 +43,7 @@ enum fixed_addresses {
> >       __end_of_fixed_addresses
> >  };
> >
> > -#define FIXMAP_PAGE_IO               PAGE_KERNEL
> > +#define FIXMAP_PAGE_IO               PAGE_IOREMAP
> >
> >  #define __early_set_fixmap   __set_fixmap
> >
> > diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h
> > index 228261aa9628..16d251282b1d 100644
> > --- a/arch/riscv/include/asm/pgtable-64.h
> > +++ b/arch/riscv/include/asm/pgtable-64.h
> > @@ -59,14 +59,29 @@ static inline void pud_clear(pud_t *pudp)
> >       set_pud(pudp, __pud(0));
> >  }
> >
> > +static inline unsigned long _chg_of_pmd(pmd_t pmd)
> > +{
> > +     return (pmd_val(pmd) & _PAGE_CHG_MASK);
> > +}
> > +
> > +static inline unsigned long _chg_of_pud(pud_t pud)
> > +{
> > +     return (pud_val(pud) & _PAGE_CHG_MASK);
> > +}
> > +
> > +static inline unsigned long _chg_of_pte(pte_t pte)
> > +{
> > +     return (pte_val(pte) & _PAGE_CHG_MASK);
> > +}
> > +
> >  static inline pmd_t *pud_pgtable(pud_t pud)
> >  {
> > -     return (pmd_t *)pfn_to_virt(pud_val(pud) >> _PAGE_PFN_SHIFT);
> > +     return (pmd_t *)pfn_to_virt(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT);
> >  }
> >
> >  static inline struct page *pud_page(pud_t pud)
> >  {
> > -     return pfn_to_page(pud_val(pud) >> _PAGE_PFN_SHIFT);
> > +     return pfn_to_page(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT);
> >  }
> >
> >  static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot)
> > @@ -76,7 +91,7 @@ static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot)
> >
> >  static inline unsigned long _pmd_pfn(pmd_t pmd)
> >  {
> > -     return pmd_val(pmd) >> _PAGE_PFN_SHIFT;
> > +     return _chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT;
> >  }
> >
> >  #define mk_pmd(page, prot)    pfn_pmd(page_to_pfn(page), prot)
> > diff --git a/arch/riscv/include/asm/pgtable-bits.h b/arch/riscv/include/asm/pgtable-bits.h
> > index 2ee413912926..e5b0fce4ddc5 100644
> > --- a/arch/riscv/include/asm/pgtable-bits.h
> > +++ b/arch/riscv/include/asm/pgtable-bits.h
> > @@ -7,7 +7,7 @@
> >  #define _ASM_RISCV_PGTABLE_BITS_H
> >
> >  /*
> > - * PTE format:
> > + * rv32 PTE format:
> >   * | XLEN-1  10 | 9             8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
> >   *       PFN      reserved for SW   D   A   G   U   X   W   R   V
> >   */
> > @@ -24,6 +24,40 @@
> >  #define _PAGE_DIRTY     (1 << 7)    /* Set by hardware on any write */
> >  #define _PAGE_SOFT      (1 << 8)    /* Reserved for software */
> >
> > +#if !defined(__ASSEMBLY__) && defined(CONFIG_64BIT)
> > +/*
> > + * rv64 PTE format:
> > + * | 63 | 62 61 | 60 54 | 53  10 | 9             8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
> > + *   N      MT     RSV    PFN      reserved for SW   D   A   G   U   X   W   R   V
> > + * [62:61] Memory Type definitions:
> > + *  00 - PMA    Normal Cacheable, No change to implied PMA memory type
> > + *  01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
> > + *  10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
> > + *  11 - Rsvd   Reserved for future standard use
> > + */
> > +#define _SVPBMT_PMA          0UL
> > +#define _SVPBMT_NC           (1UL << 61)
> > +#define _SVPBMT_IO           (1UL << 62)
> > +#define _SVPBMT_MASK         (_SVPBMT_NC | _SVPBMT_IO)
> > +
> > +extern struct __svpbmt_struct {
> > +     unsigned long mask;
> > +     unsigned long pma;
> > +     unsigned long nocache;
> > +     unsigned long io;
> > +} __svpbmt __cacheline_aligned;
> > +
> > +#define _PAGE_MASK           __svpbmt.mask
> > +#define _PAGE_PMA            __svpbmt.pma
> > +#define _PAGE_NOCACHE                __svpbmt.nocache
> > +#define _PAGE_IO             __svpbmt.io
> > +#else
> > +#define _PAGE_MASK           0
> > +#define _PAGE_PMA            0
> > +#define _PAGE_NOCACHE                0
> > +#define _PAGE_IO             0
> > +#endif /* !__ASSEMBLY__ && CONFIG_64BIT */
> > +
> >  #define _PAGE_SPECIAL   _PAGE_SOFT
> >  #define _PAGE_TABLE     _PAGE_PRESENT
> >
> > @@ -38,7 +72,8 @@
> >  /* Set of bits to preserve across pte_modify() */
> >  #define _PAGE_CHG_MASK  (~(unsigned long)(_PAGE_PRESENT | _PAGE_READ |       \
> >                                         _PAGE_WRITE | _PAGE_EXEC |    \
> > -                                       _PAGE_USER | _PAGE_GLOBAL))
> > +                                       _PAGE_USER | _PAGE_GLOBAL |   \
> > +                                       _PAGE_MASK))
> >  /*
> >   * when all of R/W/X are zero, the PTE is a pointer to the next level
> >   * of the page table; otherwise, it is a leaf PTE.
> > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
> > index bf204e7c1f74..0f7a6541015f 100644
> > --- a/arch/riscv/include/asm/pgtable.h
> > +++ b/arch/riscv/include/asm/pgtable.h
> > @@ -138,7 +138,8 @@
> >                               | _PAGE_PRESENT \
> >                               | _PAGE_ACCESSED \
> >                               | _PAGE_DIRTY \
> > -                             | _PAGE_GLOBAL)
> > +                             | _PAGE_GLOBAL \
> > +                             | _PAGE_PMA)
> >
> >  #define PAGE_KERNEL          __pgprot(_PAGE_KERNEL)
> >  #define PAGE_KERNEL_READ     __pgprot(_PAGE_KERNEL & ~_PAGE_WRITE)
> > @@ -148,11 +149,9 @@
> >
> >  #define PAGE_TABLE           __pgprot(_PAGE_TABLE)
> >
> > -/*
> > - * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't
> > - * change the properties of memory regions.
> > - */
> > -#define _PAGE_IOREMAP _PAGE_KERNEL
> > +#define _PAGE_IOREMAP        ((_PAGE_KERNEL & ~_PAGE_MASK) | _PAGE_IO)
> > +
> > +#define PAGE_IOREMAP         __pgprot(_PAGE_IOREMAP)
> >
> >  extern pgd_t swapper_pg_dir[];
> >
> > @@ -232,12 +231,12 @@ static inline unsigned long _pgd_pfn(pgd_t pgd)
> >
> >  static inline struct page *pmd_page(pmd_t pmd)
> >  {
> > -     return pfn_to_page(pmd_val(pmd) >> _PAGE_PFN_SHIFT);
> > +     return pfn_to_page(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT);
> >  }
> >
> >  static inline unsigned long pmd_page_vaddr(pmd_t pmd)
> >  {
> > -     return (unsigned long)pfn_to_virt(pmd_val(pmd) >> _PAGE_PFN_SHIFT);
> > +     return (unsigned long)pfn_to_virt(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT);
> >  }
> >
> >  static inline pte_t pmd_pte(pmd_t pmd)
> > @@ -253,7 +252,7 @@ static inline pte_t pud_pte(pud_t pud)
> >  /* Yields the page frame number (PFN) of a page table entry */
> >  static inline unsigned long pte_pfn(pte_t pte)
> >  {
> > -     return (pte_val(pte) >> _PAGE_PFN_SHIFT);
> > +     return (_chg_of_pte(pte) >> _PAGE_PFN_SHIFT);
> >  }
> >
> >  #define pte_page(x)     pfn_to_page(pte_pfn(x))
> > @@ -492,6 +491,28 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma,
> >       return ptep_test_and_clear_young(vma, address, ptep);
> >  }
> >
> > +#define pgprot_noncached pgprot_noncached
> > +static inline pgprot_t pgprot_noncached(pgprot_t _prot)
> > +{
> > +     unsigned long prot = pgprot_val(_prot);
> > +
> > +     prot &= ~_PAGE_MASK;
> > +     prot |= _PAGE_IO;
> > +
> > +     return __pgprot(prot);
> > +}
> > +
> > +#define pgprot_writecombine pgprot_writecombine
> > +static inline pgprot_t pgprot_writecombine(pgprot_t _prot)
> > +{
> > +     unsigned long prot = pgprot_val(_prot);
> > +
> > +     prot &= ~_PAGE_MASK;
> > +     prot |= _PAGE_NOCACHE;
> > +
> > +     return __pgprot(prot);
> > +}
> > +
> >  /*
> >   * THP functions
> >   */
> > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> > index d959d207a40d..fa7480cb8b87 100644
> > --- a/arch/riscv/kernel/cpufeature.c
> > +++ b/arch/riscv/kernel/cpufeature.c
> > @@ -8,6 +8,7 @@
> >
> >  #include <linux/bitmap.h>
> >  #include <linux/of.h>
> > +#include <linux/pgtable.h>
> >  #include <asm/processor.h>
> >  #include <asm/hwcap.h>
> >  #include <asm/smp.h>
> > @@ -59,6 +60,38 @@ bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit)
> >  }
> >  EXPORT_SYMBOL_GPL(__riscv_isa_extension_available);
> >
> > +static void __init mmu_supports_svpbmt(void)
> > +{
> > +#if defined(CONFIG_MMU) && defined(CONFIG_64BIT)
>
> IIRC, Christoph suggested a CONFIG_RISCV_SVPBMT when reviewing v3. What
> about that idea?

Yes, sorry for missing it, yes, I think we can have something like this

config ARCH_HAS_RISCV_SVPBMT
bool
default n

any platform which needs this support, can just

select ARCH_HAS_RISCV_SVPBMT

and which is the best name? ARCH_HAS_RISCV_SVPBMT or just ARCH_HAS_SVPBMT ?

>
> > +     struct device_node *node;
> > +     const char *str;
> > +
> > +     for_each_of_cpu_node(node) {
> > +             if (of_property_read_string(node, "mmu-type", &str))
> > +                     continue;
> > +
> > +             if (!strncmp(str + 6, "none", 4))
> > +                     continue;
> > +
> > +             if (of_property_read_string(node, "mmu", &str))
> > +                     continue;
> > +
> > +             if (strncmp(str + 6, "svpmbt", 6))
> > +                     continue;
> > +     }
> > +
> > +     __svpbmt.pma            = _SVPBMT_PMA;
> > +     __svpbmt.nocache        = _SVPBMT_NC;
> > +     __svpbmt.io             = _SVPBMT_IO;
> > +     __svpbmt.mask           = _SVPBMT_MASK;
> > +#endif
> > +}
> > +
> > +static void __init mmu_supports(void)
>
> can we remove this function currently? Instead, directly call
> mmu_supports_svpbmt()?
>
> > +{
> > +     mmu_supports_svpbmt();
> > +}
> > +
> >  void __init riscv_fill_hwcap(void)
> >  {
> >       struct device_node *node;
> > @@ -67,6 +100,8 @@ void __init riscv_fill_hwcap(void)
> >       size_t i, j, isa_len;
> >       static unsigned long isa2hwcap[256] = {0};
> >
> > +     mmu_supports();
> > +
> >       isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I;
> >       isa2hwcap['m'] = isa2hwcap['M'] = COMPAT_HWCAP_ISA_M;
> >       isa2hwcap['a'] = isa2hwcap['A'] = COMPAT_HWCAP_ISA_A;
> > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> > index 24b2b8044602..e4e658165ee1 100644
> > --- a/arch/riscv/mm/init.c
> > +++ b/arch/riscv/mm/init.c
> > @@ -854,3 +854,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
> >       return vmemmap_populate_basepages(start, end, node, NULL);
> >  }
> >  #endif
> > +
> > +#if defined(CONFIG_64BIT)
> > +struct __svpbmt_struct __svpbmt __ro_after_init;
>
> Added the structure for all RV64 including NOMMU case and those platforms
> which doen't want SVPBMT at all, I believe Christoph's CONFIG_RISCV_SVPBMT
> suggestion can solve this problem.

see ARCH_HAS_RISCV_SVPBMT above . :-)

>
> > +EXPORT_SYMBOL(__svpbmt);
> > +#endif
>

Re: [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports

[Anup Patel]

On Wed, Dec 1, 2021 at 10:35 AM Wei Fu <wefu@redhat.com> wrote:
>
> Hi, Jisheng Zhang,
>
> On Mon, Nov 29, 2021 at 9:44 PM Jisheng Zhang <jszhang@kernel.org> wrote:
> >
> > On Mon, 29 Nov 2021 09:40:07 +0800
> > wefu@redhat.com wrote:
> >
> > > From: Wei Fu <wefu@redhat.com>
> > >
> > > This patch follows the standard pure RISC-V Svpbmt extension in
> > > privilege spec to solve the non-coherent SOC dma synchronization
> > > issues.
> > >
> > > Here is the svpbmt PTE format:
> > > | 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
> > >   N     MT     RSW    D   A   G   U   X   W   R   V
> > >         ^
> > >
> > > Of the Reserved bits [63:54] in a leaf PTE, the high bit is already
> > > allocated (as the N bit), so bits [62:61] are used as the MT (aka
> > > MemType) field. This field specifies one of three memory types that
> > > are close equivalents (or equivalent in effect) to the three main x86
> > > and ARMv8 memory types - as shown in the following table.
> > >
> > > RISC-V
> > > Encoding &
> > > MemType     RISC-V Description
> > > ----------  ------------------------------------------------
> > > 00 - PMA    Normal Cacheable, No change to implied PMA memory type
> > > 01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
> > > 10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
> > > 11 - Rsvd   Reserved for future standard use
> > >
> > > The standard protection_map[] needn't be modified because the "PMA"
> > > type keeps the highest bits zero. And the whole modification is
> > > limited in the arch/riscv/* and using a global variable
> > > (__svpbmt) as _PAGE_MASK/IO/NOCACHE for pgprot_noncached
> > > (&writecombine) in pgtable.h. We also add _PAGE_CHG_MASK to filter
> > > PFN than before.
> > >
> > > Enable it in devicetree - (Add "riscv,svpbmt" in the mmu of cpu node)
> > >  - mmu:
> > >      riscv,svpmbt
> > >
> > > Signed-off-by: Wei Fu <wefu@redhat.com>
> > > Co-developed-by: Liu Shaohua <liush@allwinnertech.com>
> > > Signed-off-by: Liu Shaohua <liush@allwinnertech.com>
> > > Co-developed-by: Guo Ren <guoren@kernel.org>
> > > Signed-off-by: Guo Ren <guoren@kernel.org>
> > > Cc: Palmer Dabbelt <palmerdabbelt@google.com>
> > > Cc: Christoph Hellwig <hch@lst.de>
> > > Cc: Anup Patel <anup.patel@wdc.com>
> > > Cc: Arnd Bergmann <arnd@arndb.de>
> > > Cc: Atish Patra <atish.patra@wdc.com>
> > > Cc: Drew Fustini <drew@beagleboard.org>
> > > Cc: Wei Fu <wefu@redhat.com>
> > > Cc: Wei Wu <lazyparser@gmail.com>
> > > Cc: Chen-Yu Tsai <wens@csie.org>
> > > Cc: Maxime Ripard <maxime@cerno.tech>
> > > Cc: Daniel Lustig <dlustig@nvidia.com>
> > > Cc: Greg Favor <gfavor@ventanamicro.com>
> > > Cc: Andrea Mondelli <andrea.mondelli@huawei.com>
> > > Cc: Jonathan Behrens <behrensj@mit.edu>
> > > Cc: Xinhaoqu (Freddie) <xinhaoqu@huawei.com>
> > > Cc: Bill Huffman <huffman@cadence.com>
> > > Cc: Nick Kossifidis <mick@ics.forth.gr>
> > > Cc: Allen Baum <allen.baum@esperantotech.com>
> > > Cc: Josh Scheid <jscheid@ventanamicro.com>
> > > Cc: Richard Trauben <rtrauben@gmail.com>
> > > ---
> > >  arch/riscv/include/asm/fixmap.h       |  2 +-
> > >  arch/riscv/include/asm/pgtable-64.h   | 21 ++++++++++++---
> > >  arch/riscv/include/asm/pgtable-bits.h | 39 +++++++++++++++++++++++++--
> > >  arch/riscv/include/asm/pgtable.h      | 39 ++++++++++++++++++++-------
> > >  arch/riscv/kernel/cpufeature.c        | 35 ++++++++++++++++++++++++
> > >  arch/riscv/mm/init.c                  |  5 ++++
> > >  6 files changed, 126 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h
> > > index 54cbf07fb4e9..5acd99d08e74 100644
> > > --- a/arch/riscv/include/asm/fixmap.h
> > > +++ b/arch/riscv/include/asm/fixmap.h
> > > @@ -43,7 +43,7 @@ enum fixed_addresses {
> > >       __end_of_fixed_addresses
> > >  };
> > >
> > > -#define FIXMAP_PAGE_IO               PAGE_KERNEL
> > > +#define FIXMAP_PAGE_IO               PAGE_IOREMAP
> > >
> > >  #define __early_set_fixmap   __set_fixmap
> > >
> > > diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h
> > > index 228261aa9628..16d251282b1d 100644
> > > --- a/arch/riscv/include/asm/pgtable-64.h
> > > +++ b/arch/riscv/include/asm/pgtable-64.h
> > > @@ -59,14 +59,29 @@ static inline void pud_clear(pud_t *pudp)
> > >       set_pud(pudp, __pud(0));
> > >  }
> > >
> > > +static inline unsigned long _chg_of_pmd(pmd_t pmd)
> > > +{
> > > +     return (pmd_val(pmd) & _PAGE_CHG_MASK);
> > > +}
> > > +
> > > +static inline unsigned long _chg_of_pud(pud_t pud)
> > > +{
> > > +     return (pud_val(pud) & _PAGE_CHG_MASK);
> > > +}
> > > +
> > > +static inline unsigned long _chg_of_pte(pte_t pte)
> > > +{
> > > +     return (pte_val(pte) & _PAGE_CHG_MASK);
> > > +}
> > > +
> > >  static inline pmd_t *pud_pgtable(pud_t pud)
> > >  {
> > > -     return (pmd_t *)pfn_to_virt(pud_val(pud) >> _PAGE_PFN_SHIFT);
> > > +     return (pmd_t *)pfn_to_virt(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT);
> > >  }
> > >
> > >  static inline struct page *pud_page(pud_t pud)
> > >  {
> > > -     return pfn_to_page(pud_val(pud) >> _PAGE_PFN_SHIFT);
> > > +     return pfn_to_page(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT);
> > >  }
> > >
> > >  static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot)
> > > @@ -76,7 +91,7 @@ static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot)
> > >
> > >  static inline unsigned long _pmd_pfn(pmd_t pmd)
> > >  {
> > > -     return pmd_val(pmd) >> _PAGE_PFN_SHIFT;
> > > +     return _chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT;
> > >  }
> > >
> > >  #define mk_pmd(page, prot)    pfn_pmd(page_to_pfn(page), prot)
> > > diff --git a/arch/riscv/include/asm/pgtable-bits.h b/arch/riscv/include/asm/pgtable-bits.h
> > > index 2ee413912926..e5b0fce4ddc5 100644
> > > --- a/arch/riscv/include/asm/pgtable-bits.h
> > > +++ b/arch/riscv/include/asm/pgtable-bits.h
> > > @@ -7,7 +7,7 @@
> > >  #define _ASM_RISCV_PGTABLE_BITS_H
> > >
> > >  /*
> > > - * PTE format:
> > > + * rv32 PTE format:
> > >   * | XLEN-1  10 | 9             8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
> > >   *       PFN      reserved for SW   D   A   G   U   X   W   R   V
> > >   */
> > > @@ -24,6 +24,40 @@
> > >  #define _PAGE_DIRTY     (1 << 7)    /* Set by hardware on any write */
> > >  #define _PAGE_SOFT      (1 << 8)    /* Reserved for software */
> > >
> > > +#if !defined(__ASSEMBLY__) && defined(CONFIG_64BIT)
> > > +/*
> > > + * rv64 PTE format:
> > > + * | 63 | 62 61 | 60 54 | 53  10 | 9             8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
> > > + *   N      MT     RSV    PFN      reserved for SW   D   A   G   U   X   W   R   V
> > > + * [62:61] Memory Type definitions:
> > > + *  00 - PMA    Normal Cacheable, No change to implied PMA memory type
> > > + *  01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
> > > + *  10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
> > > + *  11 - Rsvd   Reserved for future standard use
> > > + */
> > > +#define _SVPBMT_PMA          0UL
> > > +#define _SVPBMT_NC           (1UL << 61)
> > > +#define _SVPBMT_IO           (1UL << 62)
> > > +#define _SVPBMT_MASK         (_SVPBMT_NC | _SVPBMT_IO)
> > > +
> > > +extern struct __svpbmt_struct {
> > > +     unsigned long mask;
> > > +     unsigned long pma;
> > > +     unsigned long nocache;
> > > +     unsigned long io;
> > > +} __svpbmt __cacheline_aligned;
> > > +
> > > +#define _PAGE_MASK           __svpbmt.mask
> > > +#define _PAGE_PMA            __svpbmt.pma
> > > +#define _PAGE_NOCACHE                __svpbmt.nocache
> > > +#define _PAGE_IO             __svpbmt.io
> > > +#else
> > > +#define _PAGE_MASK           0
> > > +#define _PAGE_PMA            0
> > > +#define _PAGE_NOCACHE                0
> > > +#define _PAGE_IO             0
> > > +#endif /* !__ASSEMBLY__ && CONFIG_64BIT */
> > > +
> > >  #define _PAGE_SPECIAL   _PAGE_SOFT
> > >  #define _PAGE_TABLE     _PAGE_PRESENT
> > >
> > > @@ -38,7 +72,8 @@
> > >  /* Set of bits to preserve across pte_modify() */
> > >  #define _PAGE_CHG_MASK  (~(unsigned long)(_PAGE_PRESENT | _PAGE_READ |       \
> > >                                         _PAGE_WRITE | _PAGE_EXEC |    \
> > > -                                       _PAGE_USER | _PAGE_GLOBAL))
> > > +                                       _PAGE_USER | _PAGE_GLOBAL |   \
> > > +                                       _PAGE_MASK))
> > >  /*
> > >   * when all of R/W/X are zero, the PTE is a pointer to the next level
> > >   * of the page table; otherwise, it is a leaf PTE.
> > > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
> > > index bf204e7c1f74..0f7a6541015f 100644
> > > --- a/arch/riscv/include/asm/pgtable.h
> > > +++ b/arch/riscv/include/asm/pgtable.h
> > > @@ -138,7 +138,8 @@
> > >                               | _PAGE_PRESENT \
> > >                               | _PAGE_ACCESSED \
> > >                               | _PAGE_DIRTY \
> > > -                             | _PAGE_GLOBAL)
> > > +                             | _PAGE_GLOBAL \
> > > +                             | _PAGE_PMA)
> > >
> > >  #define PAGE_KERNEL          __pgprot(_PAGE_KERNEL)
> > >  #define PAGE_KERNEL_READ     __pgprot(_PAGE_KERNEL & ~_PAGE_WRITE)
> > > @@ -148,11 +149,9 @@
> > >
> > >  #define PAGE_TABLE           __pgprot(_PAGE_TABLE)
> > >
> > > -/*
> > > - * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't
> > > - * change the properties of memory regions.
> > > - */
> > > -#define _PAGE_IOREMAP _PAGE_KERNEL
> > > +#define _PAGE_IOREMAP        ((_PAGE_KERNEL & ~_PAGE_MASK) | _PAGE_IO)
> > > +
> > > +#define PAGE_IOREMAP         __pgprot(_PAGE_IOREMAP)
> > >
> > >  extern pgd_t swapper_pg_dir[];
> > >
> > > @@ -232,12 +231,12 @@ static inline unsigned long _pgd_pfn(pgd_t pgd)
> > >
> > >  static inline struct page *pmd_page(pmd_t pmd)
> > >  {
> > > -     return pfn_to_page(pmd_val(pmd) >> _PAGE_PFN_SHIFT);
> > > +     return pfn_to_page(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT);
> > >  }
> > >
> > >  static inline unsigned long pmd_page_vaddr(pmd_t pmd)
> > >  {
> > > -     return (unsigned long)pfn_to_virt(pmd_val(pmd) >> _PAGE_PFN_SHIFT);
> > > +     return (unsigned long)pfn_to_virt(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT);
> > >  }
> > >
> > >  static inline pte_t pmd_pte(pmd_t pmd)
> > > @@ -253,7 +252,7 @@ static inline pte_t pud_pte(pud_t pud)
> > >  /* Yields the page frame number (PFN) of a page table entry */
> > >  static inline unsigned long pte_pfn(pte_t pte)
> > >  {
> > > -     return (pte_val(pte) >> _PAGE_PFN_SHIFT);
> > > +     return (_chg_of_pte(pte) >> _PAGE_PFN_SHIFT);
> > >  }
> > >
> > >  #define pte_page(x)     pfn_to_page(pte_pfn(x))
> > > @@ -492,6 +491,28 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma,
> > >       return ptep_test_and_clear_young(vma, address, ptep);
> > >  }
> > >
> > > +#define pgprot_noncached pgprot_noncached
> > > +static inline pgprot_t pgprot_noncached(pgprot_t _prot)
> > > +{
> > > +     unsigned long prot = pgprot_val(_prot);
> > > +
> > > +     prot &= ~_PAGE_MASK;
> > > +     prot |= _PAGE_IO;
> > > +
> > > +     return __pgprot(prot);
> > > +}
> > > +
> > > +#define pgprot_writecombine pgprot_writecombine
> > > +static inline pgprot_t pgprot_writecombine(pgprot_t _prot)
> > > +{
> > > +     unsigned long prot = pgprot_val(_prot);
> > > +
> > > +     prot &= ~_PAGE_MASK;
> > > +     prot |= _PAGE_NOCACHE;
> > > +
> > > +     return __pgprot(prot);
> > > +}
> > > +
> > >  /*
> > >   * THP functions
> > >   */
> > > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> > > index d959d207a40d..fa7480cb8b87 100644
> > > --- a/arch/riscv/kernel/cpufeature.c
> > > +++ b/arch/riscv/kernel/cpufeature.c
> > > @@ -8,6 +8,7 @@
> > >
> > >  #include <linux/bitmap.h>
> > >  #include <linux/of.h>
> > > +#include <linux/pgtable.h>
> > >  #include <asm/processor.h>
> > >  #include <asm/hwcap.h>
> > >  #include <asm/smp.h>
> > > @@ -59,6 +60,38 @@ bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit)
> > >  }
> > >  EXPORT_SYMBOL_GPL(__riscv_isa_extension_available);
> > >
> > > +static void __init mmu_supports_svpbmt(void)
> > > +{
> > > +#if defined(CONFIG_MMU) && defined(CONFIG_64BIT)
> >
> > IIRC, Christoph suggested a CONFIG_RISCV_SVPBMT when reviewing v3. What
> > about that idea?
>
> Yes, sorry for missing it, yes, I think we can have something like this
>
> config ARCH_HAS_RISCV_SVPBMT
> bool
> default n
>
> any platform which needs this support, can just
>
> select ARCH_HAS_RISCV_SVPBMT
>
> and which is the best name? ARCH_HAS_RISCV_SVPBMT or just ARCH_HAS_SVPBMT ?
>
> >
> > > +     struct device_node *node;
> > > +     const char *str;
> > > +
> > > +     for_each_of_cpu_node(node) {
> > > +             if (of_property_read_string(node, "mmu-type", &str))
> > > +                     continue;
> > > +
> > > +             if (!strncmp(str + 6, "none", 4))
> > > +                     continue;
> > > +
> > > +             if (of_property_read_string(node, "mmu", &str))
> > > +                     continue;
> > > +
> > > +             if (strncmp(str + 6, "svpmbt", 6))
> > > +                     continue;
> > > +     }
> > > +
> > > +     __svpbmt.pma            = _SVPBMT_PMA;
> > > +     __svpbmt.nocache        = _SVPBMT_NC;
> > > +     __svpbmt.io             = _SVPBMT_IO;
> > > +     __svpbmt.mask           = _SVPBMT_MASK;
> > > +#endif
> > > +}
> > > +
> > > +static void __init mmu_supports(void)
> >
> > can we remove this function currently? Instead, directly call
> > mmu_supports_svpbmt()?
> >
> > > +{
> > > +     mmu_supports_svpbmt();
> > > +}
> > > +
> > >  void __init riscv_fill_hwcap(void)
> > >  {
> > >       struct device_node *node;
> > > @@ -67,6 +100,8 @@ void __init riscv_fill_hwcap(void)
> > >       size_t i, j, isa_len;
> > >       static unsigned long isa2hwcap[256] = {0};
> > >
> > > +     mmu_supports();
> > > +
> > >       isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I;
> > >       isa2hwcap['m'] = isa2hwcap['M'] = COMPAT_HWCAP_ISA_M;
> > >       isa2hwcap['a'] = isa2hwcap['A'] = COMPAT_HWCAP_ISA_A;
> > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> > > index 24b2b8044602..e4e658165ee1 100644
> > > --- a/arch/riscv/mm/init.c
> > > +++ b/arch/riscv/mm/init.c
> > > @@ -854,3 +854,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
> > >       return vmemmap_populate_basepages(start, end, node, NULL);
> > >  }
> > >  #endif
> > > +
> > > +#if defined(CONFIG_64BIT)
> > > +struct __svpbmt_struct __svpbmt __ro_after_init;
> >
> > Added the structure for all RV64 including NOMMU case and those platforms
> > which doen't want SVPBMT at all, I believe Christoph's CONFIG_RISCV_SVPBMT
> > suggestion can solve this problem.
>
> see ARCH_HAS_RISCV_SVPBMT above . :-)

This config option will not align with the goal of having a unified
kernel image which works on HW with/without Svpmbt.

Better to explore code patching approaches which have zero
overhead.

Regards,
Anup

>
> >
> > > +EXPORT_SYMBOL(__svpbmt);
> > > +#endif
> >
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt

[Atish Patra]

On Tue, Nov 30, 2021 at 7:06 PM Tsukasa OI <research_trasio@irq.a4lg.com> wrote:
>
> On 2021/12/01 10:21, Atish Patra wrote:
> > On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <jrtc27@jrtc27.com> wrote:
> >>
> >> On 30 Nov 2021, at 15:01, Philipp Tomsich <philipp.tomsich@vrull.eu> wrote:
> >>>
> >>> We did touch on this in our coordination call a few weeks ago: the
> >>> grouping under mmu and the bool-entries were chosen because of their
> >>> similarity to other extensions (i.e. for Zb[abcs] there could/should
> >>> be a bool-entry under each cpu-node — for some Zv* entries a subnode
> >>> might be needed with further parameters).
> >>>
> >>> The string-based approach (as in the originally proposed "mmu-type=")
> >>> would like not scale with the proliferation of small & modular
> >>> extensions.
> >>
> >> I don’t see why the Sv* extensions need to be under an mmu node then,
> >> unless the intent is that every extension be grouped under a sub-node
> >> (which doesn’t seem viable due to extensions like Zbk*, unless you
> >> group by Ss, Sv and Z)?
> >>
> >
> > It shouldn't be. All the ISA extensions (i.e. standard, supervisor & hypervisor)
> > with prefix S,Z,H should be kept separate in a separate node for easy
> > parsing.
>
> "Easy parsing" is not quite convincing.

The device tree need to carry a very long "riscv,isa" string. The
parser need to parse
that string in memory as well.

>
> There's a reason other than that I made RFC PATCH to parse
> multi-letter extensions:
>
> v1: <http://lists.infradead.org/pipermail/linux-riscv/2021-November/010252.html>
> v2: <http://lists.infradead.org/pipermail/linux-riscv/2021-November/010350.html>
>

It's on my todo list to review the series. I think we can work
together to propose a better framework for riscv isa extensions.

> (note: those patches will break RISC-V KVM because of possible ISA
>        Manual inconsistency and discussion/resolution needed)
>
> (...continued below...)
>
> >
> > "riscv,isa" dt property will not scale at all. Just look at the few
> > extensions that were ratified this year
> > and Linux kernel needs to support them.
> >
> > "Sscofpmf", "Svpbmt", "Zicbom"
> >
> >> Also, what is going to happen to the current riscv,isa? Will that
> >> continue to exist and duplicate the info, or will kernels be required
> >> to reconstruct the string themselves if they want to display it to
> >> users?
> >>

Sorry. I missed this question earlier. See my answer below.

> >
> > This is my personal preference:
> > riscv,isa will continue to base Standard ISA extensions that have
> > single letter extensions.
> >
> > This new DT node will encode all the non-single letter extensions.
> > I am not sure if it should include some provisions for custom
> > extensions starting with X because
> > that will be platform specific.
> >
> > Again, this is just my personal preference. I will try to send a patch
> > soon so that we can initiate a broader
> > discussion of the scheme and agree/disagree on something.
>
> For supervisor-only extensions like "Svpbmt", new DT node would be a
> reasonable solution (and I would not directly object about that node).
>
> However, there's many multi-letter extensions that are useful for
> user mode.  Because "riscv,isa" is exposed via sysfs and procfs
> (/proc/cpuinfo), it can be really helpful to have multi-letter

Irrespective of the method chosen to parse the device tree in kernel,
we need to provide the extension information to the userspace.

This is what I have in mind. An individual row with comma separated
extension names for each type of extensions (Ss, Sv, Sh)
after the base extension (rv64imafdc) in /proc/cpuinfo output. I am
open to other ideas as well.

isa   rv64imafdc
isa-ext-Sv Svpbmt
isa-ext-Ss Sscofpmf
isa-ext-Sh <hypervisor related extensions>
isa-ext-Z   Zicbom

We can even explicitly name the extensions after isa-ext. However, it
may be necessary and too long.

I guess you prefer to directly print the entire "riscv,isa" string in
"isa" row in /proc/cpuinfo output.
It is probably okay with the current number of extensions available
today. However, it will become so long string
in the future that it has to be broken into multiple lines.

> extensions.  Also, current version of Spike, a RISC-V ISA Simulator
> puts all multi-letter extensions in "riscv,isa" and I thought this is
> intended.
>
> My preference:
> (1) Allow having multi-letter extensions and versions in "riscv,isa"
> (2) Adding new DT node for supervisor-related extensions would be
>     reasonable (but I don't strongly agree/disagree).
>
> Thanks,
> Tsukasa
>
> >
> >
> >
> >> As a FreeBSD developer I’m obviously not a part of many of these
> >> discussions, but what the Linux community imposes as the device tree
> >> bindings has a real impact on us.
> >>
> >> Jess
> >>
> >>> On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com> wrote:
> >>>>
> >>>> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke:
> >>>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote:
> >>>>>>>
> >>>>>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner:
> >>>>>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt:
> >>>>>>>>> On 11/29/21 02:40, wefu@redhat.com wrote:
> >>>>>>>>>> From: Wei Fu <wefu@redhat.com>
> >>>>>>>>>>
> >>>>>>>>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt"
> >>>>>>>>>> in the DT mmu node. Update dt-bindings related property here.
> >>>>>>>>>>
> >>>>>>>>>> Signed-off-by: Wei Fu <wefu@redhat.com>
> >>>>>>>>>> Co-developed-by: Guo Ren <guoren@kernel.org>
> >>>>>>>>>> Signed-off-by: Guo Ren <guoren@kernel.org>
> >>>>>>>>>> Cc: Anup Patel <anup@brainfault.org>
> >>>>>>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> >>>>>>>>>> Cc: Rob Herring <robh+dt@kernel.org>
> >>>>>>>>>> ---
> >>>>>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++
> >>>>>>>>>> 1 file changed, 10 insertions(+)
> >>>>>>>>>>
> >>>>>>>>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> >>>>>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644
> >>>>>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> >>>>>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> >>>>>>>>>> @@ -63,6 +63,16 @@ properties:
> >>>>>>>>>>      - riscv,sv48
> >>>>>>>>>>      - riscv,none
> >>>>>>>>>>
> >>>>>>>>>> +  mmu:
> >>>>>>>>>
> >>>>>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before
> >>>>>>>>> mmu-type?
> >>>>>>>>>
> >>>>>>>>>> +    description:
> >>>>>>>>>> +      Describes the CPU's MMU Standard Extensions support.
> >>>>>>>>>> +      These values originate from the RISC-V Privileged
> >>>>>>>>>> +      Specification document, available from
> >>>>>>>>>> +      https://riscv.org/specifications/
> >>>>>>>>>> +    $ref: '/schemas/types.yaml#/definitions/string'
> >>>>>>>>>> +    enum:
> >>>>>>>>>> +      - riscv,svpmbt
> >>>>>>>>>
> >>>>>>>>> The privileged specification has multiple MMU related extensions:
> >>>>>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum?
> >>>>>>>>
> >>>>>>>> I remember in some earlier version some way back there was the
> >>>>>>>> suggestion of using a sub-node instead and then adding boolean
> >>>>>>>> properties for the supported extensions.
> >>>>>>>>
> >>>>>>>> Aka something like
> >>>>>>>>   mmu {
> >>>>>>>>           riscv,svpbmt;
> >>>>>>>>   };
> >>>>>>>
> >>>>>>> For the record, I'm talking about the mail from september
> >>>>>>> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/
> >>>>>>>
> >>>>>>> So having a sub-node would make adding future extensions
> >>>>>>> way nicer.
> >>>>>>
> >>>>>> Svpbmt is just an ISA extension, and should be treated like any other.
> >>>>>> Let’s not invent two different ways of representing that in the device
> >>>>>> tree.
> >>>>>
> >>>>> Heinrich asked how the other extensions should be handled
> >>>>> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with these?
> >>>>
> >>>> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may not be
> >>>> a concrete plan for that yet, but that means you should speak with the
> >>>> people involved with such extensions and come up with something
> >>>> appropriate together.
> >>>>
> >>>> Jess
> >>>>
> >>
> >>
> >> _______________________________________________
> >> linux-riscv mailing list
> >> linux-riscv@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-riscv
> >
> >
> >
> > --
> > Regards,
> > Atish
> >
> > _______________________________________________
> > linux-riscv mailing list
> > linux-riscv@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
> >



-- 
Regards,
Atish

Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt

[Heiko Stübner]

Am Mittwoch, 1. Dezember 2021, 09:15:18 CET schrieb Atish Patra:
> On Tue, Nov 30, 2021 at 7:06 PM Tsukasa OI <research_trasio@irq.a4lg.com> wrote:
> >
> > On 2021/12/01 10:21, Atish Patra wrote:
> > > On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <jrtc27@jrtc27.com> wrote:
> > >>
> > >> On 30 Nov 2021, at 15:01, Philipp Tomsich <philipp.tomsich@vrull.eu> wrote:
> > >>>
> > >>> We did touch on this in our coordination call a few weeks ago: the
> > >>> grouping under mmu and the bool-entries were chosen because of their
> > >>> similarity to other extensions (i.e. for Zb[abcs] there could/should
> > >>> be a bool-entry under each cpu-node — for some Zv* entries a subnode
> > >>> might be needed with further parameters).
> > >>>
> > >>> The string-based approach (as in the originally proposed "mmu-type=")
> > >>> would like not scale with the proliferation of small & modular
> > >>> extensions.
> > >>
> > >> I don’t see why the Sv* extensions need to be under an mmu node then,
> > >> unless the intent is that every extension be grouped under a sub-node
> > >> (which doesn’t seem viable due to extensions like Zbk*, unless you
> > >> group by Ss, Sv and Z)?
> > >>
> > >
> > > It shouldn't be. All the ISA extensions (i.e. standard, supervisor & hypervisor)
> > > with prefix S,Z,H should be kept separate in a separate node for easy
> > > parsing.
> >
> > "Easy parsing" is not quite convincing.
> 
> The device tree need to carry a very long "riscv,isa" string. The
> parser need to parse
> that string in memory as well.
> 
> >
> > There's a reason other than that I made RFC PATCH to parse
> > multi-letter extensions:
> >
> > v1: <http://lists.infradead.org/pipermail/linux-riscv/2021-November/010252.html>
> > v2: <http://lists.infradead.org/pipermail/linux-riscv/2021-November/010350.html>
> >
> 
> It's on my todo list to review the series. I think we can work
> together to propose a better framework for riscv isa extensions.
> 
> > (note: those patches will break RISC-V KVM because of possible ISA
> >        Manual inconsistency and discussion/resolution needed)
> >
> > (...continued below...)
> >
> > >
> > > "riscv,isa" dt property will not scale at all. Just look at the few
> > > extensions that were ratified this year
> > > and Linux kernel needs to support them.
> > >
> > > "Sscofpmf", "Svpbmt", "Zicbom"
> > >
> > >> Also, what is going to happen to the current riscv,isa? Will that
> > >> continue to exist and duplicate the info, or will kernels be required
> > >> to reconstruct the string themselves if they want to display it to
> > >> users?
> > >>
> 
> Sorry. I missed this question earlier. See my answer below.
> 
> > >
> > > This is my personal preference:
> > > riscv,isa will continue to base Standard ISA extensions that have
> > > single letter extensions.
> > >
> > > This new DT node will encode all the non-single letter extensions.
> > > I am not sure if it should include some provisions for custom
> > > extensions starting with X because
> > > that will be platform specific.
> > >
> > > Again, this is just my personal preference. I will try to send a patch
> > > soon so that we can initiate a broader
> > > discussion of the scheme and agree/disagree on something.
> >
> > For supervisor-only extensions like "Svpbmt", new DT node would be a
> > reasonable solution (and I would not directly object about that node).
> >
> > However, there's many multi-letter extensions that are useful for
> > user mode.  Because "riscv,isa" is exposed via sysfs and procfs
> > (/proc/cpuinfo), it can be really helpful to have multi-letter
> 
> Irrespective of the method chosen to parse the device tree in kernel,
> we need to provide the extension information to the userspace.
> 
> This is what I have in mind. An individual row with comma separated
> extension names for each type of extensions (Ss, Sv, Sh)
> after the base extension (rv64imafdc) in /proc/cpuinfo output. I am
> open to other ideas as well.
>
> isa   rv64imafdc
> isa-ext-Sv Svpbmt
> isa-ext-Ss Sscofpmf
> isa-ext-Sh <hypervisor related extensions>
> isa-ext-Z   Zicbom
> 
> We can even explicitly name the extensions after isa-ext. However, it
> may be necessary and too long.

Aren't other architectures just using a flags [x86] or features [arm64]
line in cpuinfo to expose the available additional cpu features
as a space-separated list?

So you could also just do something similar like
isa:   rv64imafdc
isa-ext: Svpbmt Sscofpmf foo bar

That would make a nice compromise between length and readability
by users I guess?


Heiko

> I guess you prefer to directly print the entire "riscv,isa" string in
> "isa" row in /proc/cpuinfo output.
> It is probably okay with the current number of extensions available
> today. However, it will become so long string
> in the future that it has to be broken into multiple lines.
> 
> > extensions.  Also, current version of Spike, a RISC-V ISA Simulator
> > puts all multi-letter extensions in "riscv,isa" and I thought this is
> > intended.
> >
> > My preference:
> > (1) Allow having multi-letter extensions and versions in "riscv,isa"
> > (2) Adding new DT node for supervisor-related extensions would be
> >     reasonable (but I don't strongly agree/disagree).
> >
> > Thanks,
> > Tsukasa
> >
> > >
> > >
> > >
> > >> As a FreeBSD developer I’m obviously not a part of many of these
> > >> discussions, but what the Linux community imposes as the device tree
> > >> bindings has a real impact on us.
> > >>
> > >> Jess
> > >>
> > >>> On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com> wrote:
> > >>>>
> > >>>> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote:
> > >>>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke:
> > >>>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote:
> > >>>>>>>
> > >>>>>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner:
> > >>>>>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt:
> > >>>>>>>>> On 11/29/21 02:40, wefu@redhat.com wrote:
> > >>>>>>>>>> From: Wei Fu <wefu@redhat.com>
> > >>>>>>>>>>
> > >>>>>>>>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt"
> > >>>>>>>>>> in the DT mmu node. Update dt-bindings related property here.
> > >>>>>>>>>>
> > >>>>>>>>>> Signed-off-by: Wei Fu <wefu@redhat.com>
> > >>>>>>>>>> Co-developed-by: Guo Ren <guoren@kernel.org>
> > >>>>>>>>>> Signed-off-by: Guo Ren <guoren@kernel.org>
> > >>>>>>>>>> Cc: Anup Patel <anup@brainfault.org>
> > >>>>>>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> > >>>>>>>>>> Cc: Rob Herring <robh+dt@kernel.org>
> > >>>>>>>>>> ---
> > >>>>>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++
> > >>>>>>>>>> 1 file changed, 10 insertions(+)
> > >>>>>>>>>>
> > >>>>>>>>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > >>>>>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644
> > >>>>>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> > >>>>>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > >>>>>>>>>> @@ -63,6 +63,16 @@ properties:
> > >>>>>>>>>>      - riscv,sv48
> > >>>>>>>>>>      - riscv,none
> > >>>>>>>>>>
> > >>>>>>>>>> +  mmu:
> > >>>>>>>>>
> > >>>>>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before
> > >>>>>>>>> mmu-type?
> > >>>>>>>>>
> > >>>>>>>>>> +    description:
> > >>>>>>>>>> +      Describes the CPU's MMU Standard Extensions support.
> > >>>>>>>>>> +      These values originate from the RISC-V Privileged
> > >>>>>>>>>> +      Specification document, available from
> > >>>>>>>>>> +      https://riscv.org/specifications/
> > >>>>>>>>>> +    $ref: '/schemas/types.yaml#/definitions/string'
> > >>>>>>>>>> +    enum:
> > >>>>>>>>>> +      - riscv,svpmbt
> > >>>>>>>>>
> > >>>>>>>>> The privileged specification has multiple MMU related extensions:
> > >>>>>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum?
> > >>>>>>>>
> > >>>>>>>> I remember in some earlier version some way back there was the
> > >>>>>>>> suggestion of using a sub-node instead and then adding boolean
> > >>>>>>>> properties for the supported extensions.
> > >>>>>>>>
> > >>>>>>>> Aka something like
> > >>>>>>>>   mmu {
> > >>>>>>>>           riscv,svpbmt;
> > >>>>>>>>   };
> > >>>>>>>
> > >>>>>>> For the record, I'm talking about the mail from september
> > >>>>>>> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/
> > >>>>>>>
> > >>>>>>> So having a sub-node would make adding future extensions
> > >>>>>>> way nicer.
> > >>>>>>
> > >>>>>> Svpbmt is just an ISA extension, and should be treated like any other.
> > >>>>>> Let’s not invent two different ways of representing that in the device
> > >>>>>> tree.
> > >>>>>
> > >>>>> Heinrich asked how the other extensions should be handled
> > >>>>> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with these?
> > >>>>
> > >>>> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may not be
> > >>>> a concrete plan for that yet, but that means you should speak with the
> > >>>> people involved with such extensions and come up with something
> > >>>> appropriate together.
> > >>>>
> > >>>> Jess
> > >>>>
> > >>
> > >>
> > >> _______________________________________________
> > >> linux-riscv mailing list
> > >> linux-riscv@lists.infradead.org
> > >> http://lists.infradead.org/mailman/listinfo/linux-riscv
> > >
> > >
> > >
> > > --
> > > Regards,
> > > Atish
> > >
> > > _______________________________________________
> > > linux-riscv mailing list
> > > linux-riscv@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-riscv
> > >
> 
> 
> 
> 

Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt

[Heiko Stübner]

Am Mittwoch, 1. Dezember 2021, 09:41:48 CET schrieb atish patra:
> On Wed, Dec 1, 2021 at 12:30 AM Heiko Stübner <heiko@sntech.de> wrote:
> 
> > Am Mittwoch, 1. Dezember 2021, 09:15:18 CET schrieb Atish Patra:
> > > On Tue, Nov 30, 2021 at 7:06 PM Tsukasa OI <research_trasio@irq.a4lg.com>
> > wrote:
> > > >
> > > > On 2021/12/01 10:21, Atish Patra wrote:
> > > > > On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <jrtc27@jrtc27.com>
> > wrote:
> > > > >>
> > > > >> On 30 Nov 2021, at 15:01, Philipp Tomsich <philipp.tomsich@vrull.eu>
> > wrote:
> > > > >>>
> > > > >>> We did touch on this in our coordination call a few weeks ago: the
> > > > >>> grouping under mmu and the bool-entries were chosen because of
> > their
> > > > >>> similarity to other extensions (i.e. for Zb[abcs] there
> > could/should
> > > > >>> be a bool-entry under each cpu-node — for some Zv* entries a
> > subnode
> > > > >>> might be needed with further parameters).
> > > > >>>
> > > > >>> The string-based approach (as in the originally proposed
> > "mmu-type=")
> > > > >>> would like not scale with the proliferation of small & modular
> > > > >>> extensions.
> > > > >>
> > > > >> I don’t see why the Sv* extensions need to be under an mmu node
> > then,
> > > > >> unless the intent is that every extension be grouped under a
> > sub-node
> > > > >> (which doesn’t seem viable due to extensions like Zbk*, unless you
> > > > >> group by Ss, Sv and Z)?
> > > > >>
> > > > >
> > > > > It shouldn't be. All the ISA extensions (i.e. standard, supervisor &
> > hypervisor)
> > > > > with prefix S,Z,H should be kept separate in a separate node for easy
> > > > > parsing.
> > > >
> > > > "Easy parsing" is not quite convincing.
> > >
> > > The device tree need to carry a very long "riscv,isa" string. The
> > > parser need to parse
> > > that string in memory as well.
> > >
> > > >
> > > > There's a reason other than that I made RFC PATCH to parse
> > > > multi-letter extensions:
> > > >
> > > > v1: <
> > http://lists.infradead.org/pipermail/linux-riscv/2021-November/010252.html
> > >
> > > > v2: <
> > http://lists.infradead.org/pipermail/linux-riscv/2021-November/010350.html
> > >
> > > >
> > >
> > > It's on my todo list to review the series. I think we can work
> > > together to propose a better framework for riscv isa extensions.
> > >
> > > > (note: those patches will break RISC-V KVM because of possible ISA
> > > >        Manual inconsistency and discussion/resolution needed)
> > > >
> > > > (...continued below...)
> > > >
> > > > >
> > > > > "riscv,isa" dt property will not scale at all. Just look at the few
> > > > > extensions that were ratified this year
> > > > > and Linux kernel needs to support them.
> > > > >
> > > > > "Sscofpmf", "Svpbmt", "Zicbom"
> > > > >
> > > > >> Also, what is going to happen to the current riscv,isa? Will that
> > > > >> continue to exist and duplicate the info, or will kernels be
> > required
> > > > >> to reconstruct the string themselves if they want to display it to
> > > > >> users?
> > > > >>
> > >
> > > Sorry. I missed this question earlier. See my answer below.
> > >
> > > > >
> > > > > This is my personal preference:
> > > > > riscv,isa will continue to base Standard ISA extensions that have
> > > > > single letter extensions.
> > > > >
> > > > > This new DT node will encode all the non-single letter extensions.
> > > > > I am not sure if it should include some provisions for custom
> > > > > extensions starting with X because
> > > > > that will be platform specific.
> > > > >
> > > > > Again, this is just my personal preference. I will try to send a
> > patch
> > > > > soon so that we can initiate a broader
> > > > > discussion of the scheme and agree/disagree on something.
> > > >
> > > > For supervisor-only extensions like "Svpbmt", new DT node would be a
> > > > reasonable solution (and I would not directly object about that node).
> > > >
> > > > However, there's many multi-letter extensions that are useful for
> > > > user mode.  Because "riscv,isa" is exposed via sysfs and procfs
> > > > (/proc/cpuinfo), it can be really helpful to have multi-letter
> > >
> > > Irrespective of the method chosen to parse the device tree in kernel,
> > > we need to provide the extension information to the userspace.
> > >
> > > This is what I have in mind. An individual row with comma separated
> > > extension names for each type of extensions (Ss, Sv, Sh)
> > > after the base extension (rv64imafdc) in /proc/cpuinfo output. I am
> > > open to other ideas as well.
> > >
> > > isa   rv64imafdc
> > > isa-ext-Sv Svpbmt
> > > isa-ext-Ss Sscofpmf
> > > isa-ext-Sh <hypervisor related extensions>
> > > isa-ext-Z   Zicbom
> > >
> > > We can even explicitly name the extensions after isa-ext. However, it
> > > may be necessary and too long.
> >
> > Aren't other architectures just using a flags [x86] or features [arm64]
> > line in cpuinfo to expose the available additional cpu features
> > as a space-separated list?
> >
> > So you could also just do something similar like
> > isa:   rv64imafdc
> > isa-ext: Svpbmt Sscofpmf foo bar
> >
> >
> A space separated list is also fine by me.
> Should we keep all the extensions as one row or split based on the type of
> extensions (Ss, Sv, Sh,)?
> 
> When I look at the flags in x86, my eyes hurt badly ;)

On arm64
Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid

or on arm32
Features        : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm


> That's why I suggested splitting by type of extensions to improve
> readability.

Though I guess with that split you introduce more requirements on userspace?
Because things that parse cpuinfo (think some python library) will need to
be updated when some new extension category surfaces?



> > That would make a nice compromise between length and readability
> > by users I guess?
> >
> >
> > Heiko
> >
> > > I guess you prefer to directly print the entire "riscv,isa" string in
> > > "isa" row in /proc/cpuinfo output.
> > > It is probably okay with the current number of extensions available
> > > today. However, it will become so long string
> > > in the future that it has to be broken into multiple lines.
> > >
> > > > extensions.  Also, current version of Spike, a RISC-V ISA Simulator
> > > > puts all multi-letter extensions in "riscv,isa" and I thought this is
> > > > intended.
> > > >
> > > > My preference:
> > > > (1) Allow having multi-letter extensions and versions in "riscv,isa"
> > > > (2) Adding new DT node for supervisor-related extensions would be
> > > >     reasonable (but I don't strongly agree/disagree).
> > > >
> > > > Thanks,
> > > > Tsukasa
> > > >
> > > > >
> > > > >
> > > > >
> > > > >> As a FreeBSD developer I’m obviously not a part of many of these
> > > > >> discussions, but what the Linux community imposes as the device tree
> > > > >> bindings has a real impact on us.
> > > > >>
> > > > >> Jess
> > > > >>
> > > > >>> On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com>
> > wrote:
> > > > >>>>
> > > > >>>> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote:
> > > > >>>>>
> > > > >>>>> Hi,
> > > > >>>>>
> > > > >>>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica
> > Clarke:
> > > > >>>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de>
> > wrote:
> > > > >>>>>>>
> > > > >>>>>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko
> > Stübner:
> > > > >>>>>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich
> > Schuchardt:
> > > > >>>>>>>>> On 11/29/21 02:40, wefu@redhat.com wrote:
> > > > >>>>>>>>>> From: Wei Fu <wefu@redhat.com>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> Previous patch has added svpbmt in arch/riscv and add
> > "riscv,svpmbt"
> > > > >>>>>>>>>> in the DT mmu node. Update dt-bindings related property
> > here.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> Signed-off-by: Wei Fu <wefu@redhat.com>
> > > > >>>>>>>>>> Co-developed-by: Guo Ren <guoren@kernel.org>
> > > > >>>>>>>>>> Signed-off-by: Guo Ren <guoren@kernel.org>
> > > > >>>>>>>>>> Cc: Anup Patel <anup@brainfault.org>
> > > > >>>>>>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> > > > >>>>>>>>>> Cc: Rob Herring <robh+dt@kernel.org>
> > > > >>>>>>>>>> ---
> > > > >>>>>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10
> > ++++++++++
> > > > >>>>>>>>>> 1 file changed, 10 insertions(+)
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> diff --git
> > a/Documentation/devicetree/bindings/riscv/cpus.yaml
> > b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > > >>>>>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644
> > > > >>>>>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > > >>>>>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > > >>>>>>>>>> @@ -63,6 +63,16 @@ properties:
> > > > >>>>>>>>>>      - riscv,sv48
> > > > >>>>>>>>>>      - riscv,none
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> +  mmu:
> > > > >>>>>>>>>
> > > > >>>>>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu
> > before
> > > > >>>>>>>>> mmu-type?
> > > > >>>>>>>>>
> > > > >>>>>>>>>> +    description:
> > > > >>>>>>>>>> +      Describes the CPU's MMU Standard Extensions support.
> > > > >>>>>>>>>> +      These values originate from the RISC-V Privileged
> > > > >>>>>>>>>> +      Specification document, available from
> > > > >>>>>>>>>> +      https://riscv.org/specifications/
> > > > >>>>>>>>>> +    $ref: '/schemas/types.yaml#/definitions/string'
> > > > >>>>>>>>>> +    enum:
> > > > >>>>>>>>>> +      - riscv,svpmbt
> > > > >>>>>>>>>
> > > > >>>>>>>>> The privileged specification has multiple MMU related
> > extensions:
> > > > >>>>>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this
> > enum?
> > > > >>>>>>>>
> > > > >>>>>>>> I remember in some earlier version some way back there was the
> > > > >>>>>>>> suggestion of using a sub-node instead and then adding boolean
> > > > >>>>>>>> properties for the supported extensions.
> > > > >>>>>>>>
> > > > >>>>>>>> Aka something like
> > > > >>>>>>>>   mmu {
> > > > >>>>>>>>           riscv,svpbmt;
> > > > >>>>>>>>   };
> > > > >>>>>>>
> > > > >>>>>>> For the record, I'm talking about the mail from september
> > > > >>>>>>>
> > https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/
> > > > >>>>>>>
> > > > >>>>>>> So having a sub-node would make adding future extensions
> > > > >>>>>>> way nicer.
> > > > >>>>>>
> > > > >>>>>> Svpbmt is just an ISA extension, and should be treated like any
> > other.
> > > > >>>>>> Let’s not invent two different ways of representing that in the
> > device
> > > > >>>>>> tree.
> > > > >>>>>
> > > > >>>>> Heinrich asked how the other extensions should be handled
> > > > >>>>> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with
> > these?
> > > > >>>>
> > > > >>>> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may
> > not be
> > > > >>>> a concrete plan for that yet, but that means you should speak
> > with the
> > > > >>>> people involved with such extensions and come up with something
> > > > >>>> appropriate together.
> > > > >>>>
> > > > >>>> Jess
> > > > >>>>
> > > > >>
> > > > >>
> > > > >> _______________________________________________
> > > > >> linux-riscv mailing list
> > > > >> linux-riscv@lists.infradead.org
> > > > >> http://lists.infradead.org/mailman/listinfo/linux-riscv
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Regards,
> > > > > Atish
> > > > >
> > > > > _______________________________________________
> > > > > linux-riscv mailing list
> > > > > linux-riscv@lists.infradead.org
> > > > > http://lists.infradead.org/mailman/listinfo/linux-riscv
> > > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> 
> 

Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt

[Philipp Tomsich]

I hope that cpuinfo is for human consumption only, as we will inject
this info in machine-readable form via the ELF auxiliary vector.
We had briefly discussed this as part of psABI and during Kito's
presentation at LPC.

If we can agree that this is for human consumption only, then we
should aim at making it easy to read for humans (and not care too much
about how easy this will be to parse).

Philipp.


On Wed, 1 Dec 2021 at 11:21, Heiko Stübner <heiko@sntech.de> wrote:
>
> Am Mittwoch, 1. Dezember 2021, 09:41:48 CET schrieb atish patra:
> > On Wed, Dec 1, 2021 at 12:30 AM Heiko Stübner <heiko@sntech.de> wrote:
> >
> > > Am Mittwoch, 1. Dezember 2021, 09:15:18 CET schrieb Atish Patra:
> > > > On Tue, Nov 30, 2021 at 7:06 PM Tsukasa OI <research_trasio@irq.a4lg.com>
> > > wrote:
> > > > >
> > > > > On 2021/12/01 10:21, Atish Patra wrote:
> > > > > > On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <jrtc27@jrtc27.com>
> > > wrote:
> > > > > >>
> > > > > >> On 30 Nov 2021, at 15:01, Philipp Tomsich <philipp.tomsich@vrull.eu>
> > > wrote:
> > > > > >>>
> > > > > >>> We did touch on this in our coordination call a few weeks ago: the
> > > > > >>> grouping under mmu and the bool-entries were chosen because of
> > > their
> > > > > >>> similarity to other extensions (i.e. for Zb[abcs] there
> > > could/should
> > > > > >>> be a bool-entry under each cpu-node — for some Zv* entries a
> > > subnode
> > > > > >>> might be needed with further parameters).
> > > > > >>>
> > > > > >>> The string-based approach (as in the originally proposed
> > > "mmu-type=")
> > > > > >>> would like not scale with the proliferation of small & modular
> > > > > >>> extensions.
> > > > > >>
> > > > > >> I don’t see why the Sv* extensions need to be under an mmu node
> > > then,
> > > > > >> unless the intent is that every extension be grouped under a
> > > sub-node
> > > > > >> (which doesn’t seem viable due to extensions like Zbk*, unless you
> > > > > >> group by Ss, Sv and Z)?
> > > > > >>
> > > > > >
> > > > > > It shouldn't be. All the ISA extensions (i.e. standard, supervisor &
> > > hypervisor)
> > > > > > with prefix S,Z,H should be kept separate in a separate node for easy
> > > > > > parsing.
> > > > >
> > > > > "Easy parsing" is not quite convincing.
> > > >
> > > > The device tree need to carry a very long "riscv,isa" string. The
> > > > parser need to parse
> > > > that string in memory as well.
> > > >
> > > > >
> > > > > There's a reason other than that I made RFC PATCH to parse
> > > > > multi-letter extensions:
> > > > >
> > > > > v1: <
> > > http://lists.infradead.org/pipermail/linux-riscv/2021-November/010252.html
> > > >
> > > > > v2: <
> > > http://lists.infradead.org/pipermail/linux-riscv/2021-November/010350.html
> > > >
> > > > >
> > > >
> > > > It's on my todo list to review the series. I think we can work
> > > > together to propose a better framework for riscv isa extensions.
> > > >
> > > > > (note: those patches will break RISC-V KVM because of possible ISA
> > > > >        Manual inconsistency and discussion/resolution needed)
> > > > >
> > > > > (...continued below...)
> > > > >
> > > > > >
> > > > > > "riscv,isa" dt property will not scale at all. Just look at the few
> > > > > > extensions that were ratified this year
> > > > > > and Linux kernel needs to support them.
> > > > > >
> > > > > > "Sscofpmf", "Svpbmt", "Zicbom"
> > > > > >
> > > > > >> Also, what is going to happen to the current riscv,isa? Will that
> > > > > >> continue to exist and duplicate the info, or will kernels be
> > > required
> > > > > >> to reconstruct the string themselves if they want to display it to
> > > > > >> users?
> > > > > >>
> > > >
> > > > Sorry. I missed this question earlier. See my answer below.
> > > >
> > > > > >
> > > > > > This is my personal preference:
> > > > > > riscv,isa will continue to base Standard ISA extensions that have
> > > > > > single letter extensions.
> > > > > >
> > > > > > This new DT node will encode all the non-single letter extensions.
> > > > > > I am not sure if it should include some provisions for custom
> > > > > > extensions starting with X because
> > > > > > that will be platform specific.
> > > > > >
> > > > > > Again, this is just my personal preference. I will try to send a
> > > patch
> > > > > > soon so that we can initiate a broader
> > > > > > discussion of the scheme and agree/disagree on something.
> > > > >
> > > > > For supervisor-only extensions like "Svpbmt", new DT node would be a
> > > > > reasonable solution (and I would not directly object about that node).
> > > > >
> > > > > However, there's many multi-letter extensions that are useful for
> > > > > user mode.  Because "riscv,isa" is exposed via sysfs and procfs
> > > > > (/proc/cpuinfo), it can be really helpful to have multi-letter
> > > >
> > > > Irrespective of the method chosen to parse the device tree in kernel,
> > > > we need to provide the extension information to the userspace.
> > > >
> > > > This is what I have in mind. An individual row with comma separated
> > > > extension names for each type of extensions (Ss, Sv, Sh)
> > > > after the base extension (rv64imafdc) in /proc/cpuinfo output. I am
> > > > open to other ideas as well.
> > > >
> > > > isa   rv64imafdc
> > > > isa-ext-Sv Svpbmt
> > > > isa-ext-Ss Sscofpmf
> > > > isa-ext-Sh <hypervisor related extensions>
> > > > isa-ext-Z   Zicbom
> > > >
> > > > We can even explicitly name the extensions after isa-ext. However, it
> > > > may be necessary and too long.
> > >
> > > Aren't other architectures just using a flags [x86] or features [arm64]
> > > line in cpuinfo to expose the available additional cpu features
> > > as a space-separated list?
> > >
> > > So you could also just do something similar like
> > > isa:   rv64imafdc
> > > isa-ext: Svpbmt Sscofpmf foo bar
> > >
> > >
> > A space separated list is also fine by me.
> > Should we keep all the extensions as one row or split based on the type of
> > extensions (Ss, Sv, Sh,)?
> >
> > When I look at the flags in x86, my eyes hurt badly ;)
>
> On arm64
> Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
>
> or on arm32
> Features        : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
>
>
> > That's why I suggested splitting by type of extensions to improve
> > readability.
>
> Though I guess with that split you introduce more requirements on userspace?
> Because things that parse cpuinfo (think some python library) will need to
> be updated when some new extension category surfaces?
>
>
>
> > > That would make a nice compromise between length and readability
> > > by users I guess?
> > >
> > >
> > > Heiko
> > >
> > > > I guess you prefer to directly print the entire "riscv,isa" string in
> > > > "isa" row in /proc/cpuinfo output.
> > > > It is probably okay with the current number of extensions available
> > > > today. However, it will become so long string
> > > > in the future that it has to be broken into multiple lines.
> > > >
> > > > > extensions.  Also, current version of Spike, a RISC-V ISA Simulator
> > > > > puts all multi-letter extensions in "riscv,isa" and I thought this is
> > > > > intended.
> > > > >
> > > > > My preference:
> > > > > (1) Allow having multi-letter extensions and versions in "riscv,isa"
> > > > > (2) Adding new DT node for supervisor-related extensions would be
> > > > >     reasonable (but I don't strongly agree/disagree).
> > > > >
> > > > > Thanks,
> > > > > Tsukasa
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >> As a FreeBSD developer I’m obviously not a part of many of these
> > > > > >> discussions, but what the Linux community imposes as the device tree
> > > > > >> bindings has a real impact on us.
> > > > > >>
> > > > > >> Jess
> > > > > >>
> > > > > >>> On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com>
> > > wrote:
> > > > > >>>>
> > > > > >>>> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote:
> > > > > >>>>>
> > > > > >>>>> Hi,
> > > > > >>>>>
> > > > > >>>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica
> > > Clarke:
> > > > > >>>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de>
> > > wrote:
> > > > > >>>>>>>
> > > > > >>>>>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko
> > > Stübner:
> > > > > >>>>>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich
> > > Schuchardt:
> > > > > >>>>>>>>> On 11/29/21 02:40, wefu@redhat.com wrote:
> > > > > >>>>>>>>>> From: Wei Fu <wefu@redhat.com>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> Previous patch has added svpbmt in arch/riscv and add
> > > "riscv,svpmbt"
> > > > > >>>>>>>>>> in the DT mmu node. Update dt-bindings related property
> > > here.
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> Signed-off-by: Wei Fu <wefu@redhat.com>
> > > > > >>>>>>>>>> Co-developed-by: Guo Ren <guoren@kernel.org>
> > > > > >>>>>>>>>> Signed-off-by: Guo Ren <guoren@kernel.org>
> > > > > >>>>>>>>>> Cc: Anup Patel <anup@brainfault.org>
> > > > > >>>>>>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> > > > > >>>>>>>>>> Cc: Rob Herring <robh+dt@kernel.org>
> > > > > >>>>>>>>>> ---
> > > > > >>>>>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10
> > > ++++++++++
> > > > > >>>>>>>>>> 1 file changed, 10 insertions(+)
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> diff --git
> > > a/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > > > >>>>>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644
> > > > > >>>>>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > > > >>>>>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > > > >>>>>>>>>> @@ -63,6 +63,16 @@ properties:
> > > > > >>>>>>>>>>      - riscv,sv48
> > > > > >>>>>>>>>>      - riscv,none
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> +  mmu:
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu
> > > before
> > > > > >>>>>>>>> mmu-type?
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> +    description:
> > > > > >>>>>>>>>> +      Describes the CPU's MMU Standard Extensions support.
> > > > > >>>>>>>>>> +      These values originate from the RISC-V Privileged
> > > > > >>>>>>>>>> +      Specification document, available from
> > > > > >>>>>>>>>> +      https://riscv.org/specifications/
> > > > > >>>>>>>>>> +    $ref: '/schemas/types.yaml#/definitions/string'
> > > > > >>>>>>>>>> +    enum:
> > > > > >>>>>>>>>> +      - riscv,svpmbt
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> The privileged specification has multiple MMU related
> > > extensions:
> > > > > >>>>>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this
> > > enum?
> > > > > >>>>>>>>
> > > > > >>>>>>>> I remember in some earlier version some way back there was the
> > > > > >>>>>>>> suggestion of using a sub-node instead and then adding boolean
> > > > > >>>>>>>> properties for the supported extensions.
> > > > > >>>>>>>>
> > > > > >>>>>>>> Aka something like
> > > > > >>>>>>>>   mmu {
> > > > > >>>>>>>>           riscv,svpbmt;
> > > > > >>>>>>>>   };
> > > > > >>>>>>>
> > > > > >>>>>>> For the record, I'm talking about the mail from september
> > > > > >>>>>>>
> > > https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/
> > > > > >>>>>>>
> > > > > >>>>>>> So having a sub-node would make adding future extensions
> > > > > >>>>>>> way nicer.
> > > > > >>>>>>
> > > > > >>>>>> Svpbmt is just an ISA extension, and should be treated like any
> > > other.
> > > > > >>>>>> Let’s not invent two different ways of representing that in the
> > > device
> > > > > >>>>>> tree.
> > > > > >>>>>
> > > > > >>>>> Heinrich asked how the other extensions should be handled
> > > > > >>>>> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with
> > > these?
> > > > > >>>>
> > > > > >>>> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may
> > > not be
> > > > > >>>> a concrete plan for that yet, but that means you should speak
> > > with the
> > > > > >>>> people involved with such extensions and come up with something
> > > > > >>>> appropriate together.
> > > > > >>>>
> > > > > >>>> Jess
> > > > > >>>>
> > > > > >>
> > > > > >>
> > > > > >> _______________________________________________
> > > > > >> linux-riscv mailing list
> > > > > >> linux-riscv@lists.infradead.org
> > > > > >> http://lists.infradead.org/mailman/listinfo/linux-riscv
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Regards,
> > > > > > Atish
> > > > > >
> > > > > > _______________________________________________
> > > > > > linux-riscv mailing list
> > > > > > linux-riscv@lists.infradead.org
> > > > > > http://lists.infradead.org/mailman/listinfo/linux-riscv
> > > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> >
>
>
>
>

Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt

[Heiko Stübner]

Hi Atish,

Am Mittwoch, 1. Dezember 2021, 02:21:46 CET schrieb Atish Patra:
> On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <jrtc27@jrtc27.com> wrote:
> >
> > On 30 Nov 2021, at 15:01, Philipp Tomsich <philipp.tomsich@vrull.eu> wrote:
> > >
> > > We did touch on this in our coordination call a few weeks ago: the
> > > grouping under mmu and the bool-entries were chosen because of their
> > > similarity to other extensions (i.e. for Zb[abcs] there could/should
> > > be a bool-entry under each cpu-node — for some Zv* entries a subnode
> > > might be needed with further parameters).
> > >
> > > The string-based approach (as in the originally proposed "mmu-type=")
> > > would like not scale with the proliferation of small & modular
> > > extensions.
> >
> > I don’t see why the Sv* extensions need to be under an mmu node then,
> > unless the intent is that every extension be grouped under a sub-node
> > (which doesn’t seem viable due to extensions like Zbk*, unless you
> > group by Ss, Sv and Z)?
> >
> 
> It shouldn't be. All the ISA extensions (i.e. standard, supervisor & hypervisor)
> with prefix S,Z,H should be kept separate in a separate node for easy
> parsing.
> 
> "riscv,isa" dt property will not scale at all. Just look at the few
> extensions that were ratified this year
> and Linux kernel needs to support them.
> 
> "Sscofpmf", "Svpbmt", "Zicbom"
> 
> > Also, what is going to happen to the current riscv,isa? Will that
> > continue to exist and duplicate the info, or will kernels be required
> > to reconstruct the string themselves if they want to display it to
> > users?
> >
> 
> This is my personal preference:
> riscv,isa will continue to base Standard ISA extensions that have
> single letter extensions.
> 
> This new DT node will encode all the non-single letter extensions.
> I am not sure if it should include some provisions for custom
> extensions starting with X because
> that will be platform specific.
> 
> Again, this is just my personal preference. I will try to send a patch
> soon so that we can initiate a broader
> discussion of the scheme and agree/disagree on something.

that would be really helpful, as it currently looks like we have a number
of different points-of-view so discussing an actual implementation will
probably make things a lot easier compared to dancing around theoretic
cases :-) .

Out of curiosity, how soon is "soon" ? :-D


Heiko


> > As a FreeBSD developer I’m obviously not a part of many of these
> > discussions, but what the Linux community imposes as the device tree
> > bindings has a real impact on us.
> >
> > Jess
> >
> > > On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com> wrote:
> > >>
> > >> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote:
> > >>>
> > >>> Hi,
> > >>>
> > >>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke:
> > >>>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote:
> > >>>>>
> > >>>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner:
> > >>>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt:
> > >>>>>>> On 11/29/21 02:40, wefu@redhat.com wrote:
> > >>>>>>>> From: Wei Fu <wefu@redhat.com>
> > >>>>>>>>
> > >>>>>>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt"
> > >>>>>>>> in the DT mmu node. Update dt-bindings related property here.
> > >>>>>>>>
> > >>>>>>>> Signed-off-by: Wei Fu <wefu@redhat.com>
> > >>>>>>>> Co-developed-by: Guo Ren <guoren@kernel.org>
> > >>>>>>>> Signed-off-by: Guo Ren <guoren@kernel.org>
> > >>>>>>>> Cc: Anup Patel <anup@brainfault.org>
> > >>>>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> > >>>>>>>> Cc: Rob Herring <robh+dt@kernel.org>
> > >>>>>>>> ---
> > >>>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++
> > >>>>>>>> 1 file changed, 10 insertions(+)
> > >>>>>>>>
> > >>>>>>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > >>>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644
> > >>>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> > >>>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > >>>>>>>> @@ -63,6 +63,16 @@ properties:
> > >>>>>>>>      - riscv,sv48
> > >>>>>>>>      - riscv,none
> > >>>>>>>>
> > >>>>>>>> +  mmu:
> > >>>>>>>
> > >>>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before
> > >>>>>>> mmu-type?
> > >>>>>>>
> > >>>>>>>> +    description:
> > >>>>>>>> +      Describes the CPU's MMU Standard Extensions support.
> > >>>>>>>> +      These values originate from the RISC-V Privileged
> > >>>>>>>> +      Specification document, available from
> > >>>>>>>> +      https://riscv.org/specifications/
> > >>>>>>>> +    $ref: '/schemas/types.yaml#/definitions/string'
> > >>>>>>>> +    enum:
> > >>>>>>>> +      - riscv,svpmbt
> > >>>>>>>
> > >>>>>>> The privileged specification has multiple MMU related extensions:
> > >>>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum?
> > >>>>>>
> > >>>>>> I remember in some earlier version some way back there was the
> > >>>>>> suggestion of using a sub-node instead and then adding boolean
> > >>>>>> properties for the supported extensions.
> > >>>>>>
> > >>>>>> Aka something like
> > >>>>>>   mmu {
> > >>>>>>           riscv,svpbmt;
> > >>>>>>   };
> > >>>>>
> > >>>>> For the record, I'm talking about the mail from september
> > >>>>> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/
> > >>>>>
> > >>>>> So having a sub-node would make adding future extensions
> > >>>>> way nicer.
> > >>>>
> > >>>> Svpbmt is just an ISA extension, and should be treated like any other.
> > >>>> Let’s not invent two different ways of representing that in the device
> > >>>> tree.
> > >>>
> > >>> Heinrich asked how the other extensions should be handled
> > >>> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with these?
> > >>
> > >> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may not be
> > >> a concrete plan for that yet, but that means you should speak with the
> > >> people involved with such extensions and come up with something
> > >> appropriate together.
> > >>
> > >> Jess
> > >>
> >
> >
> > _______________________________________________
> > linux-riscv mailing list
> > linux-riscv@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
> 
> 
> 
> --
> Regards,
> Atish
> 

Re: [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports

[Jisheng Zhang]

On Wed, 1 Dec 2021 11:48:44 +0530
Anup Patel <anup@brainfault.org> wrote:


> > > >   */
> > > > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> > > > index d959d207a40d..fa7480cb8b87 100644
> > > > --- a/arch/riscv/kernel/cpufeature.c
> > > > +++ b/arch/riscv/kernel/cpufeature.c
> > > > @@ -8,6 +8,7 @@
> > > >
> > > >  #include <linux/bitmap.h>
> > > >  #include <linux/of.h>
> > > > +#include <linux/pgtable.h>
> > > >  #include <asm/processor.h>
> > > >  #include <asm/hwcap.h>
> > > >  #include <asm/smp.h>
> > > > @@ -59,6 +60,38 @@ bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit)
> > > >  }
> > > >  EXPORT_SYMBOL_GPL(__riscv_isa_extension_available);
> > > >
> > > > +static void __init mmu_supports_svpbmt(void)
> > > > +{
> > > > +#if defined(CONFIG_MMU) && defined(CONFIG_64BIT)  
> > >
> > > IIRC, Christoph suggested a CONFIG_RISCV_SVPBMT when reviewing v3. What
> > > about that idea?  
> >
> > Yes, sorry for missing it, yes, I think we can have something like this
> >
> > config ARCH_HAS_RISCV_SVPBMT
> > bool
> > default n
> >
> > any platform which needs this support, can just
> >
> > select ARCH_HAS_RISCV_SVPBMT
> >
> > and which is the best name? ARCH_HAS_RISCV_SVPBMT or just ARCH_HAS_SVPBMT ?
> >  
> > >  
> > > > +     struct device_node *node;
> > > > +     const char *str;
> > > > +
> > > > +     for_each_of_cpu_node(node) {
> > > > +             if (of_property_read_string(node, "mmu-type", &str))
> > > > +                     continue;
> > > > +
> > > > +             if (!strncmp(str + 6, "none", 4))
> > > > +                     continue;
> > > > +
> > > > +             if (of_property_read_string(node, "mmu", &str))
> > > > +                     continue;
> > > > +
> > > > +             if (strncmp(str + 6, "svpmbt", 6))
> > > > +                     continue;
> > > > +     }
> > > > +
> > > > +     __svpbmt.pma            = _SVPBMT_PMA;
> > > > +     __svpbmt.nocache        = _SVPBMT_NC;
> > > > +     __svpbmt.io             = _SVPBMT_IO;
> > > > +     __svpbmt.mask           = _SVPBMT_MASK;
> > > > +#endif
> > > > +}
> > > > +
> > > > +static void __init mmu_supports(void)  
> > >
> > > can we remove this function currently? Instead, directly call
> > > mmu_supports_svpbmt()?
> > >  
> > > > +{
> > > > +     mmu_supports_svpbmt();
> > > > +}
> > > > +
> > > >  void __init riscv_fill_hwcap(void)
> > > >  {
> > > >       struct device_node *node;
> > > > @@ -67,6 +100,8 @@ void __init riscv_fill_hwcap(void)
> > > >       size_t i, j, isa_len;
> > > >       static unsigned long isa2hwcap[256] = {0};
> > > >
> > > > +     mmu_supports();
> > > > +
> > > >       isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I;
> > > >       isa2hwcap['m'] = isa2hwcap['M'] = COMPAT_HWCAP_ISA_M;
> > > >       isa2hwcap['a'] = isa2hwcap['A'] = COMPAT_HWCAP_ISA_A;
> > > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> > > > index 24b2b8044602..e4e658165ee1 100644
> > > > --- a/arch/riscv/mm/init.c
> > > > +++ b/arch/riscv/mm/init.c
> > > > @@ -854,3 +854,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
> > > >       return vmemmap_populate_basepages(start, end, node, NULL);
> > > >  }
> > > >  #endif
> > > > +
> > > > +#if defined(CONFIG_64BIT)
> > > > +struct __svpbmt_struct __svpbmt __ro_after_init;  
> > >
> > > Added the structure for all RV64 including NOMMU case and those platforms
> > > which doen't want SVPBMT at all, I believe Christoph's CONFIG_RISCV_SVPBMT
> > > suggestion can solve this problem.  
> >
> > see ARCH_HAS_RISCV_SVPBMT above . :-)  
> 
> This config option will not align with the goal of having a unified
> kernel image which works on HW with/without Svpmbt.

Just my thoughts: 

If disable this option, HW without Svpbmt can work as before; Hw with
Svpbmt will only have a basic working, those DMA etc can't work.

If enable this option, HW without Svpbmt can work as well, but with
a bit overhead and waste. HW with Svpbmt can work. So this option gives
those platforms which doesn't need Svpbmt a chance to totally disable it.

But linux distributions which want a uniified Image usually enable features as
much as possible, so IMHO, this config option can still meet unified kernel
image requirement.

> 
> Better to explore code patching approaches which have zero
> overhead.

It would be nice if the Svpbmt can be supported via. coding patching tech.

Thanks

Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt

[Jessica Clarke]

On 1 Dec 2021, at 11:05, Philipp Tomsich <philipp.tomsich@vrull.eu> wrote:
> 
> I hope that cpuinfo is for human consumption only, as we will inject
> this info in machine-readable form via the ELF auxiliary vector.
> We had briefly discussed this as part of psABI and during Kito's
> presentation at LPC.
> 
> If we can agree that this is for human consumption only, then we
> should aim at making it easy to read for humans (and not care too much
> about how easy this will be to parse).

If it's human-readable then why is it formatted in such a
machine-readable way?

A lot of software parses it[1]. Including lscpu. There’s lots of
information there that won’t appear in AT_HWCAP or similar as it’s not
generally relevant to userspace (processor speed, supervisor-level
extensions, physical hartid, ...).

Jess

[1] https://codesearch.debian.net/search?q=%22%2Fproc%2Fcpuinfo%22&literal=1&perpkg=1

> On Wed, 1 Dec 2021 at 11:21, Heiko Stübner <heiko@sntech.de> wrote:
>> 
>> Am Mittwoch, 1. Dezember 2021, 09:41:48 CET schrieb atish patra:
>>> On Wed, Dec 1, 2021 at 12:30 AM Heiko Stübner <heiko@sntech.de> wrote:
>>> 
>>>> Am Mittwoch, 1. Dezember 2021, 09:15:18 CET schrieb Atish Patra:
>>>>> On Tue, Nov 30, 2021 at 7:06 PM Tsukasa OI <research_trasio@irq.a4lg.com>
>>>> wrote:
>>>>>> 
>>>>>> On 2021/12/01 10:21, Atish Patra wrote:
>>>>>>> On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <jrtc27@jrtc27.com>
>>>> wrote:
>>>>>>>> 
>>>>>>>> On 30 Nov 2021, at 15:01, Philipp Tomsich <philipp.tomsich@vrull.eu>
>>>> wrote:
>>>>>>>>> 
>>>>>>>>> We did touch on this in our coordination call a few weeks ago: the
>>>>>>>>> grouping under mmu and the bool-entries were chosen because of
>>>> their
>>>>>>>>> similarity to other extensions (i.e. for Zb[abcs] there
>>>> could/should
>>>>>>>>> be a bool-entry under each cpu-node — for some Zv* entries a
>>>> subnode
>>>>>>>>> might be needed with further parameters).
>>>>>>>>> 
>>>>>>>>> The string-based approach (as in the originally proposed
>>>> "mmu-type=")
>>>>>>>>> would like not scale with the proliferation of small & modular
>>>>>>>>> extensions.
>>>>>>>> 
>>>>>>>> I don’t see why the Sv* extensions need to be under an mmu node
>>>> then,
>>>>>>>> unless the intent is that every extension be grouped under a
>>>> sub-node
>>>>>>>> (which doesn’t seem viable due to extensions like Zbk*, unless you
>>>>>>>> group by Ss, Sv and Z)?
>>>>>>>> 
>>>>>>> 
>>>>>>> It shouldn't be. All the ISA extensions (i.e. standard, supervisor &
>>>> hypervisor)
>>>>>>> with prefix S,Z,H should be kept separate in a separate node for easy
>>>>>>> parsing.
>>>>>> 
>>>>>> "Easy parsing" is not quite convincing.
>>>>> 
>>>>> The device tree need to carry a very long "riscv,isa" string. The
>>>>> parser need to parse
>>>>> that string in memory as well.
>>>>> 
>>>>>> 
>>>>>> There's a reason other than that I made RFC PATCH to parse
>>>>>> multi-letter extensions:
>>>>>> 
>>>>>> v1: <
>>>> http://lists.infradead.org/pipermail/linux-riscv/2021-November/010252.html
>>>>> 
>>>>>> v2: <
>>>> http://lists.infradead.org/pipermail/linux-riscv/2021-November/010350.html
>>>>> 
>>>>>> 
>>>>> 
>>>>> It's on my todo list to review the series. I think we can work
>>>>> together to propose a better framework for riscv isa extensions.
>>>>> 
>>>>>> (note: those patches will break RISC-V KVM because of possible ISA
>>>>>>       Manual inconsistency and discussion/resolution needed)
>>>>>> 
>>>>>> (...continued below...)
>>>>>> 
>>>>>>> 
>>>>>>> "riscv,isa" dt property will not scale at all. Just look at the few
>>>>>>> extensions that were ratified this year
>>>>>>> and Linux kernel needs to support them.
>>>>>>> 
>>>>>>> "Sscofpmf", "Svpbmt", "Zicbom"
>>>>>>> 
>>>>>>>> Also, what is going to happen to the current riscv,isa? Will that
>>>>>>>> continue to exist and duplicate the info, or will kernels be
>>>> required
>>>>>>>> to reconstruct the string themselves if they want to display it to
>>>>>>>> users?
>>>>>>>> 
>>>>> 
>>>>> Sorry. I missed this question earlier. See my answer below.
>>>>> 
>>>>>>> 
>>>>>>> This is my personal preference:
>>>>>>> riscv,isa will continue to base Standard ISA extensions that have
>>>>>>> single letter extensions.
>>>>>>> 
>>>>>>> This new DT node will encode all the non-single letter extensions.
>>>>>>> I am not sure if it should include some provisions for custom
>>>>>>> extensions starting with X because
>>>>>>> that will be platform specific.
>>>>>>> 
>>>>>>> Again, this is just my personal preference. I will try to send a
>>>> patch
>>>>>>> soon so that we can initiate a broader
>>>>>>> discussion of the scheme and agree/disagree on something.
>>>>>> 
>>>>>> For supervisor-only extensions like "Svpbmt", new DT node would be a
>>>>>> reasonable solution (and I would not directly object about that node).
>>>>>> 
>>>>>> However, there's many multi-letter extensions that are useful for
>>>>>> user mode.  Because "riscv,isa" is exposed via sysfs and procfs
>>>>>> (/proc/cpuinfo), it can be really helpful to have multi-letter
>>>>> 
>>>>> Irrespective of the method chosen to parse the device tree in kernel,
>>>>> we need to provide the extension information to the userspace.
>>>>> 
>>>>> This is what I have in mind. An individual row with comma separated
>>>>> extension names for each type of extensions (Ss, Sv, Sh)
>>>>> after the base extension (rv64imafdc) in /proc/cpuinfo output. I am
>>>>> open to other ideas as well.
>>>>> 
>>>>> isa   rv64imafdc
>>>>> isa-ext-Sv Svpbmt
>>>>> isa-ext-Ss Sscofpmf
>>>>> isa-ext-Sh <hypervisor related extensions>
>>>>> isa-ext-Z   Zicbom
>>>>> 
>>>>> We can even explicitly name the extensions after isa-ext. However, it
>>>>> may be necessary and too long.
>>>> 
>>>> Aren't other architectures just using a flags [x86] or features [arm64]
>>>> line in cpuinfo to expose the available additional cpu features
>>>> as a space-separated list?
>>>> 
>>>> So you could also just do something similar like
>>>> isa:   rv64imafdc
>>>> isa-ext: Svpbmt Sscofpmf foo bar
>>>> 
>>>> 
>>> A space separated list is also fine by me.
>>> Should we keep all the extensions as one row or split based on the type of
>>> extensions (Ss, Sv, Sh,)?
>>> 
>>> When I look at the flags in x86, my eyes hurt badly ;)
>> 
>> On arm64
>> Features        : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
>> 
>> or on arm32
>> Features        : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm
>> 
>> 
>>> That's why I suggested splitting by type of extensions to improve
>>> readability.
>> 
>> Though I guess with that split you introduce more requirements on userspace?
>> Because things that parse cpuinfo (think some python library) will need to
>> be updated when some new extension category surfaces?
>> 
>> 
>> 
>>>> That would make a nice compromise between length and readability
>>>> by users I guess?
>>>> 
>>>> 
>>>> Heiko
>>>> 
>>>>> I guess you prefer to directly print the entire "riscv,isa" string in
>>>>> "isa" row in /proc/cpuinfo output.
>>>>> It is probably okay with the current number of extensions available
>>>>> today. However, it will become so long string
>>>>> in the future that it has to be broken into multiple lines.
>>>>> 
>>>>>> extensions.  Also, current version of Spike, a RISC-V ISA Simulator
>>>>>> puts all multi-letter extensions in "riscv,isa" and I thought this is
>>>>>> intended.
>>>>>> 
>>>>>> My preference:
>>>>>> (1) Allow having multi-letter extensions and versions in "riscv,isa"
>>>>>> (2) Adding new DT node for supervisor-related extensions would be
>>>>>>    reasonable (but I don't strongly agree/disagree).
>>>>>> 
>>>>>> Thanks,
>>>>>> Tsukasa
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> As a FreeBSD developer I’m obviously not a part of many of these
>>>>>>>> discussions, but what the Linux community imposes as the device tree
>>>>>>>> bindings has a real impact on us.
>>>>>>>> 
>>>>>>>> Jess
>>>>>>>> 
>>>>>>>>> On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com>
>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hi,
>>>>>>>>>>> 
>>>>>>>>>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica
>>>> Clarke:
>>>>>>>>>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de>
>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko
>>>> Stübner:
>>>>>>>>>>>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich
>>>> Schuchardt:
>>>>>>>>>>>>>>> On 11/29/21 02:40, wefu@redhat.com wrote:
>>>>>>>>>>>>>>>> From: Wei Fu <wefu@redhat.com>
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Previous patch has added svpbmt in arch/riscv and add
>>>> "riscv,svpmbt"
>>>>>>>>>>>>>>>> in the DT mmu node. Update dt-bindings related property
>>>> here.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Signed-off-by: Wei Fu <wefu@redhat.com>
>>>>>>>>>>>>>>>> Co-developed-by: Guo Ren <guoren@kernel.org>
>>>>>>>>>>>>>>>> Signed-off-by: Guo Ren <guoren@kernel.org>
>>>>>>>>>>>>>>>> Cc: Anup Patel <anup@brainfault.org>
>>>>>>>>>>>>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com>
>>>>>>>>>>>>>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10
>>>> ++++++++++
>>>>>>>>>>>>>>>> 1 file changed, 10 insertions(+)
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> diff --git
>>>> a/Documentation/devicetree/bindings/riscv/cpus.yaml
>>>> b/Documentation/devicetree/bindings/riscv/cpus.yaml
>>>>>>>>>>>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644
>>>>>>>>>>>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
>>>>>>>>>>>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
>>>>>>>>>>>>>>>> @@ -63,6 +63,16 @@ properties:
>>>>>>>>>>>>>>>>     - riscv,sv48
>>>>>>>>>>>>>>>>     - riscv,none
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> +  mmu:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu
>>>> before
>>>>>>>>>>>>>>> mmu-type?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> +    description:
>>>>>>>>>>>>>>>> +      Describes the CPU's MMU Standard Extensions support.
>>>>>>>>>>>>>>>> +      These values originate from the RISC-V Privileged
>>>>>>>>>>>>>>>> +      Specification document, available from
>>>>>>>>>>>>>>>> +      https://riscv.org/specifications/
>>>>>>>>>>>>>>>> +    $ref: '/schemas/types.yaml#/definitions/string'
>>>>>>>>>>>>>>>> +    enum:
>>>>>>>>>>>>>>>> +      - riscv,svpmbt
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> The privileged specification has multiple MMU related
>>>> extensions:
>>>>>>>>>>>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this
>>>> enum?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> I remember in some earlier version some way back there was the
>>>>>>>>>>>>>> suggestion of using a sub-node instead and then adding boolean
>>>>>>>>>>>>>> properties for the supported extensions.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Aka something like
>>>>>>>>>>>>>>  mmu {
>>>>>>>>>>>>>>          riscv,svpbmt;
>>>>>>>>>>>>>>  };
>>>>>>>>>>>>> 
>>>>>>>>>>>>> For the record, I'm talking about the mail from september
>>>>>>>>>>>>> 
>>>> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/
>>>>>>>>>>>>> 
>>>>>>>>>>>>> So having a sub-node would make adding future extensions
>>>>>>>>>>>>> way nicer.
>>>>>>>>>>>> 
>>>>>>>>>>>> Svpbmt is just an ISA extension, and should be treated like any
>>>> other.
>>>>>>>>>>>> Let’s not invent two different ways of representing that in the
>>>> device
>>>>>>>>>>>> tree.
>>>>>>>>>>> 
>>>>>>>>>>> Heinrich asked how the other extensions should be handled
>>>>>>>>>>> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with
>>>> these?
>>>>>>>>>> 
>>>>>>>>>> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may
>>>> not be
>>>>>>>>>> a concrete plan for that yet, but that means you should speak
>>>> with the
>>>>>>>>>> people involved with such extensions and come up with something
>>>>>>>>>> appropriate together.
>>>>>>>>>> 
>>>>>>>>>> Jess
>>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> linux-riscv mailing list
>>>>>>>> linux-riscv@lists.infradead.org
>>>>>>>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Regards,
>>>>>>> Atish
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> linux-riscv mailing list
>>>>>>> linux-riscv@lists.infradead.org
>>>>>>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
>> 
>> 

Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt

[Tsukasa OI]

On 2021/12/01 17:15, Atish Patra wrote:
> On Tue, Nov 30, 2021 at 7:06 PM Tsukasa OI <research_trasio@irq.a4lg.com> wrote:
>>
>> On 2021/12/01 10:21, Atish Patra wrote:
>>> On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <jrtc27@jrtc27.com> wrote:
>>>>
>>>> On 30 Nov 2021, at 15:01, Philipp Tomsich <philipp.tomsich@vrull.eu> wrote:
>>>>>
>>>>> We did touch on this in our coordination call a few weeks ago: the
>>>>> grouping under mmu and the bool-entries were chosen because of their
>>>>> similarity to other extensions (i.e. for Zb[abcs] there could/should
>>>>> be a bool-entry under each cpu-node — for some Zv* entries a subnode
>>>>> might be needed with further parameters).
>>>>>
>>>>> The string-based approach (as in the originally proposed "mmu-type=")
>>>>> would like not scale with the proliferation of small & modular
>>>>> extensions.
>>>>
>>>> I don’t see why the Sv* extensions need to be under an mmu node then,
>>>> unless the intent is that every extension be grouped under a sub-node
>>>> (which doesn’t seem viable due to extensions like Zbk*, unless you
>>>> group by Ss, Sv and Z)?
>>>>
>>>
>>> It shouldn't be. All the ISA extensions (i.e. standard, supervisor & hypervisor)
>>> with prefix S,Z,H should be kept separate in a separate node for easy
>>> parsing.
>>
>> "Easy parsing" is not quite convincing.
> 
> The device tree need to carry a very long "riscv,isa" string. The
> parser need to parse
> that string in memory as well.
> 
>>
>> There's a reason other than that I made RFC PATCH to parse
>> multi-letter extensions:
>>
>> v1: <http://lists.infradead.org/pipermail/linux-riscv/2021-November/010252.html>
>> v2: <http://lists.infradead.org/pipermail/linux-riscv/2021-November/010350.html>
>>
> 
> It's on my todo list to review the series. I think we can work
> together to propose a better framework for riscv isa extensions.

Thanks.  I will submit RFC PATCH v3 today so that we can start a healthy
discussion.  I apologize that I missed so many points and there's a lot
things to learn.

As far as I know, if we make new DT nodes for separate extensions, we have
to (at least) synchronize the implementation with Spike.  This simulator
accepts ISA string through `--isa' option and (by default) puts entire ISA
string into the device tree as "riscv,isa" (after expansion
"G" -> "IMAFD").

Of course, it includes "Svpbmt", in which we are discussing.

    spike --isa=rv64g_zba_zbb_zbc_zbs_svinval_svnapot_svpbmt ...

I am just wondering whether breaking this behavior would worth it.

IMHO, we could create new DT nodes **and** in addition, we can possibly
use "riscv,isa" as a fallback.
I'm not sure that this would work (just changing Spike might be better)
but I ...think... it's worth discussing it.

> 
>> (note: those patches will break RISC-V KVM because of possible ISA
>>        Manual inconsistency and discussion/resolution needed)
>>
>> (...continued below...)
>>
>>>
>>> "riscv,isa" dt property will not scale at all. Just look at the few
>>> extensions that were ratified this year
>>> and Linux kernel needs to support them.
>>>
>>> "Sscofpmf", "Svpbmt", "Zicbom"
>>>
>>>> Also, what is going to happen to the current riscv,isa? Will that
>>>> continue to exist and duplicate the info, or will kernels be required
>>>> to reconstruct the string themselves if they want to display it to
>>>> users?
>>>>
> 
> Sorry. I missed this question earlier. See my answer below.
> 
>>>
>>> This is my personal preference:
>>> riscv,isa will continue to base Standard ISA extensions that have
>>> single letter extensions.
>>>
>>> This new DT node will encode all the non-single letter extensions.
>>> I am not sure if it should include some provisions for custom
>>> extensions starting with X because
>>> that will be platform specific.
>>>
>>> Again, this is just my personal preference. I will try to send a patch
>>> soon so that we can initiate a broader
>>> discussion of the scheme and agree/disagree on something.
>>
>> For supervisor-only extensions like "Svpbmt", new DT node would be a
>> reasonable solution (and I would not directly object about that node).
>>
>> However, there's many multi-letter extensions that are useful for
>> user mode.  Because "riscv,isa" is exposed via sysfs and procfs
>> (/proc/cpuinfo), it can be really helpful to have multi-letter
> 
> Irrespective of the method chosen to parse the device tree in kernel,
> we need to provide the extension information to the userspace.
> 
> This is what I have in mind. An individual row with comma separated
> extension names for each type of extensions (Ss, Sv, Sh)
> after the base extension (rv64imafdc) in /proc/cpuinfo output. I am
> open to other ideas as well.
> 
> isa   rv64imafdc
> isa-ext-Sv Svpbmt
> isa-ext-Ss Sscofpmf
> isa-ext-Sh <hypervisor related extensions>
> isa-ext-Z   Zicbom
> 
> We can even explicitly name the extensions after isa-ext. However, it
> may be necessary and too long.
> 
> I guess you prefer to directly print the entire "riscv,isa" string in
> "isa" row in /proc/cpuinfo output.
> It is probably okay with the current number of extensions available
> today. However, it will become so long string
> in the future that it has to be broken into multiple lines.
> 
>> extensions.  Also, current version of Spike, a RISC-V ISA Simulator
>> puts all multi-letter extensions in "riscv,isa" and I thought this is
>> intended.
>>
>> My preference:
>> (1) Allow having multi-letter extensions and versions in "riscv,isa"
>> (2) Adding new DT node for supervisor-related extensions would be
>>     reasonable (but I don't strongly agree/disagree).
>>
>> Thanks,
>> Tsukasa
>>
>>>
>>>
>>>
>>>> As a FreeBSD developer I’m obviously not a part of many of these
>>>> discussions, but what the Linux community imposes as the device tree
>>>> bindings has a real impact on us.
>>>>
>>>> Jess
>>>>
>>>>> On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com> wrote:
>>>>>>
>>>>>> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke:
>>>>>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote:
>>>>>>>>>
>>>>>>>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner:
>>>>>>>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt:
>>>>>>>>>>> On 11/29/21 02:40, wefu@redhat.com wrote:
>>>>>>>>>>>> From: Wei Fu <wefu@redhat.com>
>>>>>>>>>>>>
>>>>>>>>>>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt"
>>>>>>>>>>>> in the DT mmu node. Update dt-bindings related property here.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Wei Fu <wefu@redhat.com>
>>>>>>>>>>>> Co-developed-by: Guo Ren <guoren@kernel.org>
>>>>>>>>>>>> Signed-off-by: Guo Ren <guoren@kernel.org>
>>>>>>>>>>>> Cc: Anup Patel <anup@brainfault.org>
>>>>>>>>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com>
>>>>>>>>>>>> Cc: Rob Herring <robh+dt@kernel.org>
>>>>>>>>>>>> ---
>>>>>>>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++
>>>>>>>>>>>> 1 file changed, 10 insertions(+)
>>>>>>>>>>>>
>>>>>>>>>>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
>>>>>>>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644
>>>>>>>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
>>>>>>>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
>>>>>>>>>>>> @@ -63,6 +63,16 @@ properties:
>>>>>>>>>>>>      - riscv,sv48
>>>>>>>>>>>>      - riscv,none
>>>>>>>>>>>>
>>>>>>>>>>>> +  mmu:
>>>>>>>>>>>
>>>>>>>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before
>>>>>>>>>>> mmu-type?
>>>>>>>>>>>
>>>>>>>>>>>> +    description:
>>>>>>>>>>>> +      Describes the CPU's MMU Standard Extensions support.
>>>>>>>>>>>> +      These values originate from the RISC-V Privileged
>>>>>>>>>>>> +      Specification document, available from
>>>>>>>>>>>> +      https://riscv.org/specifications/
>>>>>>>>>>>> +    $ref: '/schemas/types.yaml#/definitions/string'
>>>>>>>>>>>> +    enum:
>>>>>>>>>>>> +      - riscv,svpmbt
>>>>>>>>>>>
>>>>>>>>>>> The privileged specification has multiple MMU related extensions:
>>>>>>>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum?
>>>>>>>>>>
>>>>>>>>>> I remember in some earlier version some way back there was the
>>>>>>>>>> suggestion of using a sub-node instead and then adding boolean
>>>>>>>>>> properties for the supported extensions.
>>>>>>>>>>
>>>>>>>>>> Aka something like
>>>>>>>>>>   mmu {
>>>>>>>>>>           riscv,svpbmt;
>>>>>>>>>>   };
>>>>>>>>>
>>>>>>>>> For the record, I'm talking about the mail from september
>>>>>>>>> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/
>>>>>>>>>
>>>>>>>>> So having a sub-node would make adding future extensions
>>>>>>>>> way nicer.
>>>>>>>>
>>>>>>>> Svpbmt is just an ISA extension, and should be treated like any other.
>>>>>>>> Let’s not invent two different ways of representing that in the device
>>>>>>>> tree.
>>>>>>>
>>>>>>> Heinrich asked how the other extensions should be handled
>>>>>>> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with these?
>>>>>>
>>>>>> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may not be
>>>>>> a concrete plan for that yet, but that means you should speak with the
>>>>>> people involved with such extensions and come up with something
>>>>>> appropriate together.
>>>>>>
>>>>>> Jess
>>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> linux-riscv mailing list
>>>> linux-riscv@lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Atish
>>>
>>> _______________________________________________
>>> linux-riscv mailing list
>>> linux-riscv@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>>>
> 
> 
> 

Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt

[Atish Patra]

On Wed, Dec 1, 2021 at 5:31 PM Tsukasa OI <research_trasio@irq.a4lg.com> wrote:
>
> On 2021/12/01 17:15, Atish Patra wrote:
> > On Tue, Nov 30, 2021 at 7:06 PM Tsukasa OI <research_trasio@irq.a4lg.com> wrote:
> >>
> >> On 2021/12/01 10:21, Atish Patra wrote:
> >>> On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <jrtc27@jrtc27.com> wrote:
> >>>>
> >>>> On 30 Nov 2021, at 15:01, Philipp Tomsich <philipp.tomsich@vrull.eu> wrote:
> >>>>>
> >>>>> We did touch on this in our coordination call a few weeks ago: the
> >>>>> grouping under mmu and the bool-entries were chosen because of their
> >>>>> similarity to other extensions (i.e. for Zb[abcs] there could/should
> >>>>> be a bool-entry under each cpu-node — for some Zv* entries a subnode
> >>>>> might be needed with further parameters).
> >>>>>
> >>>>> The string-based approach (as in the originally proposed "mmu-type=")
> >>>>> would like not scale with the proliferation of small & modular
> >>>>> extensions.
> >>>>
> >>>> I don’t see why the Sv* extensions need to be under an mmu node then,
> >>>> unless the intent is that every extension be grouped under a sub-node
> >>>> (which doesn’t seem viable due to extensions like Zbk*, unless you
> >>>> group by Ss, Sv and Z)?
> >>>>
> >>>
> >>> It shouldn't be. All the ISA extensions (i.e. standard, supervisor & hypervisor)
> >>> with prefix S,Z,H should be kept separate in a separate node for easy
> >>> parsing.
> >>
> >> "Easy parsing" is not quite convincing.
> >
> > The device tree need to carry a very long "riscv,isa" string. The
> > parser need to parse
> > that string in memory as well.
> >
> >>
> >> There's a reason other than that I made RFC PATCH to parse
> >> multi-letter extensions:
> >>
> >> v1: <http://lists.infradead.org/pipermail/linux-riscv/2021-November/010252.html>
> >> v2: <http://lists.infradead.org/pipermail/linux-riscv/2021-November/010350.html>
> >>
> >
> > It's on my todo list to review the series. I think we can work
> > together to propose a better framework for riscv isa extensions.
>
> Thanks.  I will submit RFC PATCH v3 today so that we can start a healthy
> discussion.  I apologize that I missed so many points and there's a lot
> things to learn.
>
> As far as I know, if we make new DT nodes for separate extensions, we have
> to (at least) synchronize the implementation with Spike.  This simulator
> accepts ISA string through `--isa' option and (by default) puts entire ISA
> string into the device tree as "riscv,isa" (after expansion
> "G" -> "IMAFD").
>
> Of course, it includes "Svpbmt", in which we are discussing.
>
>     spike --isa=rv64g_zba_zbb_zbc_zbs_svinval_svnapot_svpbmt ...
>
> I am just wondering whether breaking this behavior would worth it.
>
> IMHO, we could create new DT nodes **and** in addition, we can possibly
> use "riscv,isa" as a fallback.

I don't think that would be necessary. We can just fix the spike implementation
if a separate DT node approach is accepted upstream.

The device tree formation is Linux specific. Given that we will have a
well defined DT binding
for the new DT node, it is enough to change the spike.

> I'm not sure that this would work (just changing Spike might be better)
> but I ...think... it's worth discussing it.
>
> >
> >> (note: those patches will break RISC-V KVM because of possible ISA
> >>        Manual inconsistency and discussion/resolution needed)
> >>
> >> (...continued below...)
> >>
> >>>
> >>> "riscv,isa" dt property will not scale at all. Just look at the few
> >>> extensions that were ratified this year
> >>> and Linux kernel needs to support them.
> >>>
> >>> "Sscofpmf", "Svpbmt", "Zicbom"
> >>>
> >>>> Also, what is going to happen to the current riscv,isa? Will that
> >>>> continue to exist and duplicate the info, or will kernels be required
> >>>> to reconstruct the string themselves if they want to display it to
> >>>> users?
> >>>>
> >
> > Sorry. I missed this question earlier. See my answer below.
> >
> >>>
> >>> This is my personal preference:
> >>> riscv,isa will continue to base Standard ISA extensions that have
> >>> single letter extensions.
> >>>
> >>> This new DT node will encode all the non-single letter extensions.
> >>> I am not sure if it should include some provisions for custom
> >>> extensions starting with X because
> >>> that will be platform specific.
> >>>
> >>> Again, this is just my personal preference. I will try to send a patch
> >>> soon so that we can initiate a broader
> >>> discussion of the scheme and agree/disagree on something.
> >>
> >> For supervisor-only extensions like "Svpbmt", new DT node would be a
> >> reasonable solution (and I would not directly object about that node).
> >>
> >> However, there's many multi-letter extensions that are useful for
> >> user mode.  Because "riscv,isa" is exposed via sysfs and procfs
> >> (/proc/cpuinfo), it can be really helpful to have multi-letter
> >
> > Irrespective of the method chosen to parse the device tree in kernel,
> > we need to provide the extension information to the userspace.
> >
> > This is what I have in mind. An individual row with comma separated
> > extension names for each type of extensions (Ss, Sv, Sh)
> > after the base extension (rv64imafdc) in /proc/cpuinfo output. I am
> > open to other ideas as well.
> >
> > isa   rv64imafdc
> > isa-ext-Sv Svpbmt
> > isa-ext-Ss Sscofpmf
> > isa-ext-Sh <hypervisor related extensions>
> > isa-ext-Z   Zicbom
> >
> > We can even explicitly name the extensions after isa-ext. However, it
> > may be necessary and too long.
> >
> > I guess you prefer to directly print the entire "riscv,isa" string in
> > "isa" row in /proc/cpuinfo output.
> > It is probably okay with the current number of extensions available
> > today. However, it will become so long string
> > in the future that it has to be broken into multiple lines.
> >
> >> extensions.  Also, current version of Spike, a RISC-V ISA Simulator
> >> puts all multi-letter extensions in "riscv,isa" and I thought this is
> >> intended.
> >>
> >> My preference:
> >> (1) Allow having multi-letter extensions and versions in "riscv,isa"
> >> (2) Adding new DT node for supervisor-related extensions would be
> >>     reasonable (but I don't strongly agree/disagree).
> >>
> >> Thanks,
> >> Tsukasa
> >>
> >>>
> >>>
> >>>
> >>>> As a FreeBSD developer I’m obviously not a part of many of these
> >>>> discussions, but what the Linux community imposes as the device tree
> >>>> bindings has a real impact on us.
> >>>>
> >>>> Jess
> >>>>
> >>>>> On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com> wrote:
> >>>>>>
> >>>>>> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote:
> >>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke:
> >>>>>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote:
> >>>>>>>>>
> >>>>>>>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner:
> >>>>>>>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt:
> >>>>>>>>>>> On 11/29/21 02:40, wefu@redhat.com wrote:
> >>>>>>>>>>>> From: Wei Fu <wefu@redhat.com>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt"
> >>>>>>>>>>>> in the DT mmu node. Update dt-bindings related property here.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Signed-off-by: Wei Fu <wefu@redhat.com>
> >>>>>>>>>>>> Co-developed-by: Guo Ren <guoren@kernel.org>
> >>>>>>>>>>>> Signed-off-by: Guo Ren <guoren@kernel.org>
> >>>>>>>>>>>> Cc: Anup Patel <anup@brainfault.org>
> >>>>>>>>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> >>>>>>>>>>>> Cc: Rob Herring <robh+dt@kernel.org>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++
> >>>>>>>>>>>> 1 file changed, 10 insertions(+)
> >>>>>>>>>>>>
> >>>>>>>>>>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> >>>>>>>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644
> >>>>>>>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> >>>>>>>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> >>>>>>>>>>>> @@ -63,6 +63,16 @@ properties:
> >>>>>>>>>>>>      - riscv,sv48
> >>>>>>>>>>>>      - riscv,none
> >>>>>>>>>>>>
> >>>>>>>>>>>> +  mmu:
> >>>>>>>>>>>
> >>>>>>>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before
> >>>>>>>>>>> mmu-type?
> >>>>>>>>>>>
> >>>>>>>>>>>> +    description:
> >>>>>>>>>>>> +      Describes the CPU's MMU Standard Extensions support.
> >>>>>>>>>>>> +      These values originate from the RISC-V Privileged
> >>>>>>>>>>>> +      Specification document, available from
> >>>>>>>>>>>> +      https://riscv.org/specifications/
> >>>>>>>>>>>> +    $ref: '/schemas/types.yaml#/definitions/string'
> >>>>>>>>>>>> +    enum:
> >>>>>>>>>>>> +      - riscv,svpmbt
> >>>>>>>>>>>
> >>>>>>>>>>> The privileged specification has multiple MMU related extensions:
> >>>>>>>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum?
> >>>>>>>>>>
> >>>>>>>>>> I remember in some earlier version some way back there was the
> >>>>>>>>>> suggestion of using a sub-node instead and then adding boolean
> >>>>>>>>>> properties for the supported extensions.
> >>>>>>>>>>
> >>>>>>>>>> Aka something like
> >>>>>>>>>>   mmu {
> >>>>>>>>>>           riscv,svpbmt;
> >>>>>>>>>>   };
> >>>>>>>>>
> >>>>>>>>> For the record, I'm talking about the mail from september
> >>>>>>>>> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/
> >>>>>>>>>
> >>>>>>>>> So having a sub-node would make adding future extensions
> >>>>>>>>> way nicer.
> >>>>>>>>
> >>>>>>>> Svpbmt is just an ISA extension, and should be treated like any other.
> >>>>>>>> Let’s not invent two different ways of representing that in the device
> >>>>>>>> tree.
> >>>>>>>
> >>>>>>> Heinrich asked how the other extensions should be handled
> >>>>>>> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with these?
> >>>>>>
> >>>>>> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may not be
> >>>>>> a concrete plan for that yet, but that means you should speak with the
> >>>>>> people involved with such extensions and come up with something
> >>>>>> appropriate together.
> >>>>>>
> >>>>>> Jess
> >>>>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> linux-riscv mailing list
> >>>> linux-riscv@lists.infradead.org
> >>>> http://lists.infradead.org/mailman/listinfo/linux-riscv
> >>>
> >>>
> >>>
> >>> --
> >>> Regards,
> >>> Atish
> >>>
> >>> _______________________________________________
> >>> linux-riscv mailing list
> >>> linux-riscv@lists.infradead.org
> >>> http://lists.infradead.org/mailman/listinfo/linux-riscv
> >>>
> >
> >
> >



-- 
Regards,
Atish

Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt

[Atish Patra]

On Wed, Dec 1, 2021 at 5:28 AM Heiko Stübner <heiko@sntech.de> wrote:
>
> Hi Atish,
>
> Am Mittwoch, 1. Dezember 2021, 02:21:46 CET schrieb Atish Patra:
> > On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <jrtc27@jrtc27.com> wrote:
> > >
> > > On 30 Nov 2021, at 15:01, Philipp Tomsich <philipp.tomsich@vrull.eu> wrote:
> > > >
> > > > We did touch on this in our coordination call a few weeks ago: the
> > > > grouping under mmu and the bool-entries were chosen because of their
> > > > similarity to other extensions (i.e. for Zb[abcs] there could/should
> > > > be a bool-entry under each cpu-node — for some Zv* entries a subnode
> > > > might be needed with further parameters).
> > > >
> > > > The string-based approach (as in the originally proposed "mmu-type=")
> > > > would like not scale with the proliferation of small & modular
> > > > extensions.
> > >
> > > I don’t see why the Sv* extensions need to be under an mmu node then,
> > > unless the intent is that every extension be grouped under a sub-node
> > > (which doesn’t seem viable due to extensions like Zbk*, unless you
> > > group by Ss, Sv and Z)?
> > >
> >
> > It shouldn't be. All the ISA extensions (i.e. standard, supervisor & hypervisor)
> > with prefix S,Z,H should be kept separate in a separate node for easy
> > parsing.
> >
> > "riscv,isa" dt property will not scale at all. Just look at the few
> > extensions that were ratified this year
> > and Linux kernel needs to support them.
> >
> > "Sscofpmf", "Svpbmt", "Zicbom"
> >
> > > Also, what is going to happen to the current riscv,isa? Will that
> > > continue to exist and duplicate the info, or will kernels be required
> > > to reconstruct the string themselves if they want to display it to
> > > users?
> > >
> >
> > This is my personal preference:
> > riscv,isa will continue to base Standard ISA extensions that have
> > single letter extensions.
> >
> > This new DT node will encode all the non-single letter extensions.
> > I am not sure if it should include some provisions for custom
> > extensions starting with X because
> > that will be platform specific.
> >
> > Again, this is just my personal preference. I will try to send a patch
> > soon so that we can initiate a broader
> > discussion of the scheme and agree/disagree on something.
>
> that would be really helpful, as it currently looks like we have a number
> of different points-of-view so discussing an actual implementation will
> probably make things a lot easier compared to dancing around theoretic
> cases :-) .
>
> Out of curiosity, how soon is "soon" ? :-D
>

I will be on vacation for next week and I need to wrap up a few other
things before that.
Thus, soon may not be the "soon" you are expecting ;).

If you or Tsukasa have some free cycles, feel free to send the patch
in the meantime.

>
> Heiko
>
>
> > > As a FreeBSD developer I’m obviously not a part of many of these
> > > discussions, but what the Linux community imposes as the device tree
> > > bindings has a real impact on us.
> > >
> > > Jess
> > >
> > > > On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com> wrote:
> > > >>
> > > >> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote:
> > > >>>
> > > >>> Hi,
> > > >>>
> > > >>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke:
> > > >>>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote:
> > > >>>>>
> > > >>>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner:
> > > >>>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt:
> > > >>>>>>> On 11/29/21 02:40, wefu@redhat.com wrote:
> > > >>>>>>>> From: Wei Fu <wefu@redhat.com>
> > > >>>>>>>>
> > > >>>>>>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt"
> > > >>>>>>>> in the DT mmu node. Update dt-bindings related property here.
> > > >>>>>>>>
> > > >>>>>>>> Signed-off-by: Wei Fu <wefu@redhat.com>
> > > >>>>>>>> Co-developed-by: Guo Ren <guoren@kernel.org>
> > > >>>>>>>> Signed-off-by: Guo Ren <guoren@kernel.org>
> > > >>>>>>>> Cc: Anup Patel <anup@brainfault.org>
> > > >>>>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> > > >>>>>>>> Cc: Rob Herring <robh+dt@kernel.org>
> > > >>>>>>>> ---
> > > >>>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++
> > > >>>>>>>> 1 file changed, 10 insertions(+)
> > > >>>>>>>>
> > > >>>>>>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > >>>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644
> > > >>>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > >>>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > >>>>>>>> @@ -63,6 +63,16 @@ properties:
> > > >>>>>>>>      - riscv,sv48
> > > >>>>>>>>      - riscv,none
> > > >>>>>>>>
> > > >>>>>>>> +  mmu:
> > > >>>>>>>
> > > >>>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before
> > > >>>>>>> mmu-type?
> > > >>>>>>>
> > > >>>>>>>> +    description:
> > > >>>>>>>> +      Describes the CPU's MMU Standard Extensions support.
> > > >>>>>>>> +      These values originate from the RISC-V Privileged
> > > >>>>>>>> +      Specification document, available from
> > > >>>>>>>> +      https://riscv.org/specifications/
> > > >>>>>>>> +    $ref: '/schemas/types.yaml#/definitions/string'
> > > >>>>>>>> +    enum:
> > > >>>>>>>> +      - riscv,svpmbt
> > > >>>>>>>
> > > >>>>>>> The privileged specification has multiple MMU related extensions:
> > > >>>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum?
> > > >>>>>>
> > > >>>>>> I remember in some earlier version some way back there was the
> > > >>>>>> suggestion of using a sub-node instead and then adding boolean
> > > >>>>>> properties for the supported extensions.
> > > >>>>>>
> > > >>>>>> Aka something like
> > > >>>>>>   mmu {
> > > >>>>>>           riscv,svpbmt;
> > > >>>>>>   };
> > > >>>>>
> > > >>>>> For the record, I'm talking about the mail from september
> > > >>>>> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/
> > > >>>>>
> > > >>>>> So having a sub-node would make adding future extensions
> > > >>>>> way nicer.
> > > >>>>
> > > >>>> Svpbmt is just an ISA extension, and should be treated like any other.
> > > >>>> Let’s not invent two different ways of representing that in the device
> > > >>>> tree.
> > > >>>
> > > >>> Heinrich asked how the other extensions should be handled
> > > >>> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with these?
> > > >>
> > > >> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may not be
> > > >> a concrete plan for that yet, but that means you should speak with the
> > > >> people involved with such extensions and come up with something
> > > >> appropriate together.
> > > >>
> > > >> Jess
> > > >>
> > >
> > >
> > > _______________________________________________
> > > linux-riscv mailing list
> > > linux-riscv@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-riscv
> >
> >
> >
> > --
> > Regards,
> > Atish
> >
>
>
>
>


-- 
Regards,
Atish

Re: [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports

[Wei Fu]

Hi Anup,

On Wed, Dec 1, 2021 at 2:19 PM Anup Patel <anup@brainfault.org> wrote:
>
> On Wed, Dec 1, 2021 at 10:35 AM Wei Fu <wefu@redhat.com> wrote:
> >
> > Hi, Jisheng Zhang,
> >
> > On Mon, Nov 29, 2021 at 9:44 PM Jisheng Zhang <jszhang@kernel.org> wrote:
> > >
> > > On Mon, 29 Nov 2021 09:40:07 +0800
> > > wefu@redhat.com wrote:
> > >
> > > > From: Wei Fu <wefu@redhat.com>
> > > >
> > > > This patch follows the standard pure RISC-V Svpbmt extension in
> > > > privilege spec to solve the non-coherent SOC dma synchronization
> > > > issues.
> > > >
> > > > Here is the svpbmt PTE format:
> > > > | 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
> > > >   N     MT     RSW    D   A   G   U   X   W   R   V
> > > >         ^
> > > >
> > > > Of the Reserved bits [63:54] in a leaf PTE, the high bit is already
> > > > allocated (as the N bit), so bits [62:61] are used as the MT (aka
> > > > MemType) field. This field specifies one of three memory types that
> > > > are close equivalents (or equivalent in effect) to the three main x86
> > > > and ARMv8 memory types - as shown in the following table.
> > > >
> > > > RISC-V
> > > > Encoding &
> > > > MemType     RISC-V Description
> > > > ----------  ------------------------------------------------
> > > > 00 - PMA    Normal Cacheable, No change to implied PMA memory type
> > > > 01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
> > > > 10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
> > > > 11 - Rsvd   Reserved for future standard use
> > > >
> > > > The standard protection_map[] needn't be modified because the "PMA"
> > > > type keeps the highest bits zero. And the whole modification is
> > > > limited in the arch/riscv/* and using a global variable
> > > > (__svpbmt) as _PAGE_MASK/IO/NOCACHE for pgprot_noncached
> > > > (&writecombine) in pgtable.h. We also add _PAGE_CHG_MASK to filter
> > > > PFN than before.
> > > >
> > > > Enable it in devicetree - (Add "riscv,svpbmt" in the mmu of cpu node)
> > > >  - mmu:
> > > >      riscv,svpmbt
> > > >
> > > > Signed-off-by: Wei Fu <wefu@redhat.com>
> > > > Co-developed-by: Liu Shaohua <liush@allwinnertech.com>
> > > > Signed-off-by: Liu Shaohua <liush@allwinnertech.com>
> > > > Co-developed-by: Guo Ren <guoren@kernel.org>
> > > > Signed-off-by: Guo Ren <guoren@kernel.org>
> > > > Cc: Palmer Dabbelt <palmerdabbelt@google.com>
> > > > Cc: Christoph Hellwig <hch@lst.de>
> > > > Cc: Anup Patel <anup.patel@wdc.com>
> > > > Cc: Arnd Bergmann <arnd@arndb.de>
> > > > Cc: Atish Patra <atish.patra@wdc.com>
> > > > Cc: Drew Fustini <drew@beagleboard.org>
> > > > Cc: Wei Fu <wefu@redhat.com>
> > > > Cc: Wei Wu <lazyparser@gmail.com>
> > > > Cc: Chen-Yu Tsai <wens@csie.org>
> > > > Cc: Maxime Ripard <maxime@cerno.tech>
> > > > Cc: Daniel Lustig <dlustig@nvidia.com>
> > > > Cc: Greg Favor <gfavor@ventanamicro.com>
> > > > Cc: Andrea Mondelli <andrea.mondelli@huawei.com>
> > > > Cc: Jonathan Behrens <behrensj@mit.edu>
> > > > Cc: Xinhaoqu (Freddie) <xinhaoqu@huawei.com>
> > > > Cc: Bill Huffman <huffman@cadence.com>
> > > > Cc: Nick Kossifidis <mick@ics.forth.gr>
> > > > Cc: Allen Baum <allen.baum@esperantotech.com>
> > > > Cc: Josh Scheid <jscheid@ventanamicro.com>
> > > > Cc: Richard Trauben <rtrauben@gmail.com>
> > > > ---
> > > >  arch/riscv/include/asm/fixmap.h       |  2 +-
> > > >  arch/riscv/include/asm/pgtable-64.h   | 21 ++++++++++++---
> > > >  arch/riscv/include/asm/pgtable-bits.h | 39 +++++++++++++++++++++++++--
> > > >  arch/riscv/include/asm/pgtable.h      | 39 ++++++++++++++++++++-------
> > > >  arch/riscv/kernel/cpufeature.c        | 35 ++++++++++++++++++++++++
> > > >  arch/riscv/mm/init.c                  |  5 ++++
> > > >  6 files changed, 126 insertions(+), 15 deletions(-)
> > > >
> > > > diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h
> > > > index 54cbf07fb4e9..5acd99d08e74 100644
> > > > --- a/arch/riscv/include/asm/fixmap.h
> > > > +++ b/arch/riscv/include/asm/fixmap.h
> > > > @@ -43,7 +43,7 @@ enum fixed_addresses {
> > > >       __end_of_fixed_addresses
> > > >  };
> > > >
> > > > -#define FIXMAP_PAGE_IO               PAGE_KERNEL
> > > > +#define FIXMAP_PAGE_IO               PAGE_IOREMAP
> > > >
> > > >  #define __early_set_fixmap   __set_fixmap
> > > >
> > > > diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h
> > > > index 228261aa9628..16d251282b1d 100644
> > > > --- a/arch/riscv/include/asm/pgtable-64.h
> > > > +++ b/arch/riscv/include/asm/pgtable-64.h
> > > > @@ -59,14 +59,29 @@ static inline void pud_clear(pud_t *pudp)
> > > >       set_pud(pudp, __pud(0));
> > > >  }
> > > >
> > > > +static inline unsigned long _chg_of_pmd(pmd_t pmd)
> > > > +{
> > > > +     return (pmd_val(pmd) & _PAGE_CHG_MASK);
> > > > +}
> > > > +
> > > > +static inline unsigned long _chg_of_pud(pud_t pud)
> > > > +{
> > > > +     return (pud_val(pud) & _PAGE_CHG_MASK);
> > > > +}
> > > > +
> > > > +static inline unsigned long _chg_of_pte(pte_t pte)
> > > > +{
> > > > +     return (pte_val(pte) & _PAGE_CHG_MASK);
> > > > +}
> > > > +
> > > >  static inline pmd_t *pud_pgtable(pud_t pud)
> > > >  {
> > > > -     return (pmd_t *)pfn_to_virt(pud_val(pud) >> _PAGE_PFN_SHIFT);
> > > > +     return (pmd_t *)pfn_to_virt(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT);
> > > >  }
> > > >
> > > >  static inline struct page *pud_page(pud_t pud)
> > > >  {
> > > > -     return pfn_to_page(pud_val(pud) >> _PAGE_PFN_SHIFT);
> > > > +     return pfn_to_page(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT);
> > > >  }
> > > >
> > > >  static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot)
> > > > @@ -76,7 +91,7 @@ static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot)
> > > >
> > > >  static inline unsigned long _pmd_pfn(pmd_t pmd)
> > > >  {
> > > > -     return pmd_val(pmd) >> _PAGE_PFN_SHIFT;
> > > > +     return _chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT;
> > > >  }
> > > >
> > > >  #define mk_pmd(page, prot)    pfn_pmd(page_to_pfn(page), prot)
> > > > diff --git a/arch/riscv/include/asm/pgtable-bits.h b/arch/riscv/include/asm/pgtable-bits.h
> > > > index 2ee413912926..e5b0fce4ddc5 100644
> > > > --- a/arch/riscv/include/asm/pgtable-bits.h
> > > > +++ b/arch/riscv/include/asm/pgtable-bits.h
> > > > @@ -7,7 +7,7 @@
> > > >  #define _ASM_RISCV_PGTABLE_BITS_H
> > > >
> > > >  /*
> > > > - * PTE format:
> > > > + * rv32 PTE format:
> > > >   * | XLEN-1  10 | 9             8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
> > > >   *       PFN      reserved for SW   D   A   G   U   X   W   R   V
> > > >   */
> > > > @@ -24,6 +24,40 @@
> > > >  #define _PAGE_DIRTY     (1 << 7)    /* Set by hardware on any write */
> > > >  #define _PAGE_SOFT      (1 << 8)    /* Reserved for software */
> > > >
> > > > +#if !defined(__ASSEMBLY__) && defined(CONFIG_64BIT)
> > > > +/*
> > > > + * rv64 PTE format:
> > > > + * | 63 | 62 61 | 60 54 | 53  10 | 9             8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0
> > > > + *   N      MT     RSV    PFN      reserved for SW   D   A   G   U   X   W   R   V
> > > > + * [62:61] Memory Type definitions:
> > > > + *  00 - PMA    Normal Cacheable, No change to implied PMA memory type
> > > > + *  01 - NC     Non-cacheable, idempotent, weakly-ordered Main Memory
> > > > + *  10 - IO     Non-cacheable, non-idempotent, strongly-ordered I/O memory
> > > > + *  11 - Rsvd   Reserved for future standard use
> > > > + */
> > > > +#define _SVPBMT_PMA          0UL
> > > > +#define _SVPBMT_NC           (1UL << 61)
> > > > +#define _SVPBMT_IO           (1UL << 62)
> > > > +#define _SVPBMT_MASK         (_SVPBMT_NC | _SVPBMT_IO)
> > > > +
> > > > +extern struct __svpbmt_struct {
> > > > +     unsigned long mask;
> > > > +     unsigned long pma;
> > > > +     unsigned long nocache;
> > > > +     unsigned long io;
> > > > +} __svpbmt __cacheline_aligned;
> > > > +
> > > > +#define _PAGE_MASK           __svpbmt.mask
> > > > +#define _PAGE_PMA            __svpbmt.pma
> > > > +#define _PAGE_NOCACHE                __svpbmt.nocache
> > > > +#define _PAGE_IO             __svpbmt.io
> > > > +#else
> > > > +#define _PAGE_MASK           0
> > > > +#define _PAGE_PMA            0
> > > > +#define _PAGE_NOCACHE                0
> > > > +#define _PAGE_IO             0
> > > > +#endif /* !__ASSEMBLY__ && CONFIG_64BIT */
> > > > +
> > > >  #define _PAGE_SPECIAL   _PAGE_SOFT
> > > >  #define _PAGE_TABLE     _PAGE_PRESENT
> > > >
> > > > @@ -38,7 +72,8 @@
> > > >  /* Set of bits to preserve across pte_modify() */
> > > >  #define _PAGE_CHG_MASK  (~(unsigned long)(_PAGE_PRESENT | _PAGE_READ |       \
> > > >                                         _PAGE_WRITE | _PAGE_EXEC |    \
> > > > -                                       _PAGE_USER | _PAGE_GLOBAL))
> > > > +                                       _PAGE_USER | _PAGE_GLOBAL |   \
> > > > +                                       _PAGE_MASK))
> > > >  /*
> > > >   * when all of R/W/X are zero, the PTE is a pointer to the next level
> > > >   * of the page table; otherwise, it is a leaf PTE.
> > > > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
> > > > index bf204e7c1f74..0f7a6541015f 100644
> > > > --- a/arch/riscv/include/asm/pgtable.h
> > > > +++ b/arch/riscv/include/asm/pgtable.h
> > > > @@ -138,7 +138,8 @@
> > > >                               | _PAGE_PRESENT \
> > > >                               | _PAGE_ACCESSED \
> > > >                               | _PAGE_DIRTY \
> > > > -                             | _PAGE_GLOBAL)
> > > > +                             | _PAGE_GLOBAL \
> > > > +                             | _PAGE_PMA)
> > > >
> > > >  #define PAGE_KERNEL          __pgprot(_PAGE_KERNEL)
> > > >  #define PAGE_KERNEL_READ     __pgprot(_PAGE_KERNEL & ~_PAGE_WRITE)
> > > > @@ -148,11 +149,9 @@
> > > >
> > > >  #define PAGE_TABLE           __pgprot(_PAGE_TABLE)
> > > >
> > > > -/*
> > > > - * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't
> > > > - * change the properties of memory regions.
> > > > - */
> > > > -#define _PAGE_IOREMAP _PAGE_KERNEL
> > > > +#define _PAGE_IOREMAP        ((_PAGE_KERNEL & ~_PAGE_MASK) | _PAGE_IO)
> > > > +
> > > > +#define PAGE_IOREMAP         __pgprot(_PAGE_IOREMAP)
> > > >
> > > >  extern pgd_t swapper_pg_dir[];
> > > >
> > > > @@ -232,12 +231,12 @@ static inline unsigned long _pgd_pfn(pgd_t pgd)
> > > >
> > > >  static inline struct page *pmd_page(pmd_t pmd)
> > > >  {
> > > > -     return pfn_to_page(pmd_val(pmd) >> _PAGE_PFN_SHIFT);
> > > > +     return pfn_to_page(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT);
> > > >  }
> > > >
> > > >  static inline unsigned long pmd_page_vaddr(pmd_t pmd)
> > > >  {
> > > > -     return (unsigned long)pfn_to_virt(pmd_val(pmd) >> _PAGE_PFN_SHIFT);
> > > > +     return (unsigned long)pfn_to_virt(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT);
> > > >  }
> > > >
> > > >  static inline pte_t pmd_pte(pmd_t pmd)
> > > > @@ -253,7 +252,7 @@ static inline pte_t pud_pte(pud_t pud)
> > > >  /* Yields the page frame number (PFN) of a page table entry */
> > > >  static inline unsigned long pte_pfn(pte_t pte)
> > > >  {
> > > > -     return (pte_val(pte) >> _PAGE_PFN_SHIFT);
> > > > +     return (_chg_of_pte(pte) >> _PAGE_PFN_SHIFT);
> > > >  }
> > > >
> > > >  #define pte_page(x)     pfn_to_page(pte_pfn(x))
> > > > @@ -492,6 +491,28 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma,
> > > >       return ptep_test_and_clear_young(vma, address, ptep);
> > > >  }
> > > >
> > > > +#define pgprot_noncached pgprot_noncached
> > > > +static inline pgprot_t pgprot_noncached(pgprot_t _prot)
> > > > +{
> > > > +     unsigned long prot = pgprot_val(_prot);
> > > > +
> > > > +     prot &= ~_PAGE_MASK;
> > > > +     prot |= _PAGE_IO;
> > > > +
> > > > +     return __pgprot(prot);
> > > > +}
> > > > +
> > > > +#define pgprot_writecombine pgprot_writecombine
> > > > +static inline pgprot_t pgprot_writecombine(pgprot_t _prot)
> > > > +{
> > > > +     unsigned long prot = pgprot_val(_prot);
> > > > +
> > > > +     prot &= ~_PAGE_MASK;
> > > > +     prot |= _PAGE_NOCACHE;
> > > > +
> > > > +     return __pgprot(prot);
> > > > +}
> > > > +
> > > >  /*
> > > >   * THP functions
> > > >   */
> > > > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> > > > index d959d207a40d..fa7480cb8b87 100644
> > > > --- a/arch/riscv/kernel/cpufeature.c
> > > > +++ b/arch/riscv/kernel/cpufeature.c
> > > > @@ -8,6 +8,7 @@
> > > >
> > > >  #include <linux/bitmap.h>
> > > >  #include <linux/of.h>
> > > > +#include <linux/pgtable.h>
> > > >  #include <asm/processor.h>
> > > >  #include <asm/hwcap.h>
> > > >  #include <asm/smp.h>
> > > > @@ -59,6 +60,38 @@ bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit)
> > > >  }
> > > >  EXPORT_SYMBOL_GPL(__riscv_isa_extension_available);
> > > >
> > > > +static void __init mmu_supports_svpbmt(void)
> > > > +{
> > > > +#if defined(CONFIG_MMU) && defined(CONFIG_64BIT)
> > >
> > > IIRC, Christoph suggested a CONFIG_RISCV_SVPBMT when reviewing v3. What
> > > about that idea?
> >
> > Yes, sorry for missing it, yes, I think we can have something like this
> >
> > config ARCH_HAS_RISCV_SVPBMT
> > bool
> > default n
> >
> > any platform which needs this support, can just
> >
> > select ARCH_HAS_RISCV_SVPBMT
> >
> > and which is the best name? ARCH_HAS_RISCV_SVPBMT or just ARCH_HAS_SVPBMT ?
> >
> > >
> > > > +     struct device_node *node;
> > > > +     const char *str;
> > > > +
> > > > +     for_each_of_cpu_node(node) {
> > > > +             if (of_property_read_string(node, "mmu-type", &str))
> > > > +                     continue;
> > > > +
> > > > +             if (!strncmp(str + 6, "none", 4))
> > > > +                     continue;
> > > > +
> > > > +             if (of_property_read_string(node, "mmu", &str))
> > > > +                     continue;
> > > > +
> > > > +             if (strncmp(str + 6, "svpmbt", 6))
> > > > +                     continue;
> > > > +     }
> > > > +
> > > > +     __svpbmt.pma            = _SVPBMT_PMA;
> > > > +     __svpbmt.nocache        = _SVPBMT_NC;
> > > > +     __svpbmt.io             = _SVPBMT_IO;
> > > > +     __svpbmt.mask           = _SVPBMT_MASK;
> > > > +#endif
> > > > +}
> > > > +
> > > > +static void __init mmu_supports(void)
> > >
> > > can we remove this function currently? Instead, directly call
> > > mmu_supports_svpbmt()?
> > >
> > > > +{
> > > > +     mmu_supports_svpbmt();
> > > > +}
> > > > +
> > > >  void __init riscv_fill_hwcap(void)
> > > >  {
> > > >       struct device_node *node;
> > > > @@ -67,6 +100,8 @@ void __init riscv_fill_hwcap(void)
> > > >       size_t i, j, isa_len;
> > > >       static unsigned long isa2hwcap[256] = {0};
> > > >
> > > > +     mmu_supports();
> > > > +
> > > >       isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I;
> > > >       isa2hwcap['m'] = isa2hwcap['M'] = COMPAT_HWCAP_ISA_M;
> > > >       isa2hwcap['a'] = isa2hwcap['A'] = COMPAT_HWCAP_ISA_A;
> > > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> > > > index 24b2b8044602..e4e658165ee1 100644
> > > > --- a/arch/riscv/mm/init.c
> > > > +++ b/arch/riscv/mm/init.c
> > > > @@ -854,3 +854,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
> > > >       return vmemmap_populate_basepages(start, end, node, NULL);
> > > >  }
> > > >  #endif
> > > > +
> > > > +#if defined(CONFIG_64BIT)
> > > > +struct __svpbmt_struct __svpbmt __ro_after_init;
> > >
> > > Added the structure for all RV64 including NOMMU case and those platforms
> > > which doen't want SVPBMT at all, I believe Christoph's CONFIG_RISCV_SVPBMT
> > > suggestion can solve this problem.
> >
> > see ARCH_HAS_RISCV_SVPBMT above . :-)
>
> This config option will not align with the goal of having a unified
> kernel image which works on HW with/without Svpmbt.
>
> Better to explore code patching approaches which have zero
> overhead.

Sure, I think Heiko has some Idea about code patching , and I will
wait for his new patches for this mechanism

>
> Regards,
> Anup
>
> >
> > >
> > > > +EXPORT_SYMBOL(__svpbmt);
> > > > +#endif
> > >
> >
> >
> > _______________________________________________
> > linux-riscv mailing list
> > linux-riscv@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
>