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

[permalink] [raw]

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

Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt:
> On 11/29/21 02:40, [email protected] wrote:
> > From: Wei Fu <[email protected]>
> >
> > 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 <[email protected]>
> > Co-developed-by: Guo Ren <[email protected]>
> > Signed-off-by: Guo Ren <[email protected]>
> > Cc: Anup Patel <[email protected]>
> > Cc: Palmer Dabbelt <[email protected]>
> > Cc: Rob Herring <[email protected]>
> > ---
> > 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
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-riscv
>

2021-11-29 13:46:10

by Jisheng Zhang

[permalink] [raw]

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

On Mon, 29 Nov 2021 09:40:07 +0800
[email protected] wrote:

> From: Wei Fu <[email protected]>
>
> 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 <[email protected]>
> Co-developed-by: Liu Shaohua <[email protected]>
> Signed-off-by: Liu Shaohua <[email protected]>
> Co-developed-by: Guo Ren <[email protected]>
> Signed-off-by: Guo Ren <[email protected]>
> Cc: Palmer Dabbelt <[email protected]>
> Cc: Christoph Hellwig <[email protected]>
> Cc: Anup Patel <[email protected]>
> Cc: Arnd Bergmann <[email protected]>
> Cc: Atish Patra <[email protected]>
> Cc: Drew Fustini <[email protected]>
> Cc: Wei Fu <[email protected]>
> Cc: Wei Wu <[email protected]>
> Cc: Chen-Yu Tsai <[email protected]>
> Cc: Maxime Ripard <[email protected]>
> Cc: Daniel Lustig <[email protected]>
> Cc: Greg Favor <[email protected]>
> Cc: Andrea Mondelli <[email protected]>
> Cc: Jonathan Behrens <[email protected]>
> Cc: Xinhaoqu (Freddie) <[email protected]>
> Cc: Bill Huffman <[email protected]>
> Cc: Nick Kossifidis <[email protected]>
> Cc: Allen Baum <[email protected]>
> Cc: Josh Scheid <[email protected]>
> Cc: Richard Trauben <[email protected]>
> ---
> 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

2021-11-29 15:28:40

by Jisheng Zhang

[permalink] [raw]

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

On Mon, 29 Nov 2021 09:40:05 +0800
[email protected] wrote:

> From: Fu Wei <[email protected]>
>
> 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(-)
>

2021-11-30 10:19:04

by Guo Ren

[permalink] [raw]

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

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 <[email protected]> wrote:
>
> From: Wei Fu <[email protected]>
>
> 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 <[email protected]>
> Co-developed-by: Liu Shaohua <[email protected]>
> Signed-off-by: Liu Shaohua <[email protected]>
> Co-developed-by: Guo Ren <[email protected]>
> Signed-off-by: Guo Ren <[email protected]>
> Cc: Palmer Dabbelt <[email protected]>
> Cc: Christoph Hellwig <[email protected]>
> Cc: Anup Patel <[email protected]>
> Cc: Arnd Bergmann <[email protected]>
> Cc: Atish Patra <[email protected]>
> Cc: Drew Fustini <[email protected]>
> Cc: Wei Fu <[email protected]>
> Cc: Wei Wu <[email protected]>
> Cc: Chen-Yu Tsai <[email protected]>
> Cc: Maxime Ripard <[email protected]>
> Cc: Daniel Lustig <[email protected]>
> Cc: Greg Favor <[email protected]>
> Cc: Andrea Mondelli <[email protected]>
> Cc: Jonathan Behrens <[email protected]>
> Cc: Xinhaoqu (Freddie) <[email protected]>
> Cc: Bill Huffman <[email protected]>
> Cc: Nick Kossifidis <[email protected]>
> Cc: Allen Baum <[email protected]>
> Cc: Josh Scheid <[email protected]>
> Cc: Richard Trauben <[email protected]>
> ---
> 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/

2021-11-30 12:07:54

[permalink] [raw]

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

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, [email protected] wrote:
> > > From: Wei Fu <[email protected]>
> > >
> > > 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 <[email protected]>
> > > Co-developed-by: Guo Ren <[email protected]>
> > > Signed-off-by: Guo Ren <[email protected]>
> > > Cc: Anup Patel <[email protected]>
> > > Cc: Palmer Dabbelt <[email protected]>
> > > Cc: Rob Herring <[email protected]>
> > > ---
> > > 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
> > [email protected]
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
> >
>
>
>
>
>
> _______________________________________________
> linux-riscv mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-riscv
>

2021-11-30 13:17:59

[permalink] [raw]

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

On 30 Nov 2021, at 12:07, Heiko Stübner <[email protected]> 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, [email protected] wrote:
>>>> From: Wei Fu <[email protected]>
>>>>
>>>> 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 <[email protected]>
>>>> Co-developed-by: Guo Ren <[email protected]>
>>>> Signed-off-by: Guo Ren <[email protected]>
>>>> Cc: Anup Patel <[email protected]>
>>>> Cc: Palmer Dabbelt <[email protected]>
>>>> Cc: Rob Herring <[email protected]>
>>>> ---
>>>> 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

2021-11-30 13:28:02

[permalink] [raw]

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

Hi,

Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke:
> On 30 Nov 2021, at 12:07, Heiko Stübner <[email protected]> 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, [email protected] wrote:
> >>>> From: Wei Fu <[email protected]>
> >>>>
> >>>> 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 <[email protected]>
> >>>> Co-developed-by: Guo Ren <[email protected]>
> >>>> Signed-off-by: Guo Ren <[email protected]>
> >>>> Cc: Anup Patel <[email protected]>
> >>>> Cc: Palmer Dabbelt <[email protected]>
> >>>> Cc: Rob Herring <[email protected]>
> >>>> ---
> >>>> 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

2021-11-30 14:00:31

[permalink] [raw]

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

On 30 Nov 2021, at 13:27, Heiko Stübner <[email protected]> wrote:
>
> Hi,
>
> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke:
>> On 30 Nov 2021, at 12:07, Heiko Stübner <[email protected]> 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, [email protected] wrote:
>>>>>> From: Wei Fu <[email protected]>
>>>>>>
>>>>>> 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 <[email protected]>
>>>>>> Co-developed-by: Guo Ren <[email protected]>
>>>>>> Signed-off-by: Guo Ren <[email protected]>
>>>>>> Cc: Anup Patel <[email protected]>
>>>>>> Cc: Palmer Dabbelt <[email protected]>
>>>>>> Cc: Rob Herring <[email protected]>
>>>>>> ---
>>>>>> 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

2021-11-30 15:14:27

by Philipp Tomsich

[permalink] [raw]

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

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 <[email protected]> wrote:
>
> On 30 Nov 2021, at 13:27, Heiko Stübner <[email protected]> wrote:
> >
> > Hi,
> >
> > Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke:
> >> On 30 Nov 2021, at 12:07, Heiko Stübner <[email protected]> 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, [email protected] wrote:
> >>>>>> From: Wei Fu <[email protected]>
> >>>>>>
> >>>>>> 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 <[email protected]>
> >>>>>> Co-developed-by: Guo Ren <[email protected]>
> >>>>>> Signed-off-by: Guo Ren <[email protected]>
> >>>>>> Cc: Anup Patel <[email protected]>
> >>>>>> Cc: Palmer Dabbelt <[email protected]>
> >>>>>> Cc: Rob Herring <[email protected]>
> >>>>>> ---
> >>>>>> 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
>

2021-11-30 16:13:01

[permalink] [raw]

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

On 30 Nov 2021, at 15:01, Philipp Tomsich <[email protected]> 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 <[email protected]> wrote:
>>
>> On 30 Nov 2021, at 13:27, Heiko Stübner <[email protected]> wrote:
>>>
>>> Hi,
>>>
>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke:
>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <[email protected]> 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, [email protected] wrote:
>>>>>>>> From: Wei Fu <[email protected]>
>>>>>>>>
>>>>>>>> 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 <[email protected]>
>>>>>>>> Co-developed-by: Guo Ren <[email protected]>
>>>>>>>> Signed-off-by: Guo Ren <[email protected]>
>>>>>>>> Cc: Anup Patel <[email protected]>
>>>>>>>> Cc: Palmer Dabbelt <[email protected]>
>>>>>>>> Cc: Rob Herring <[email protected]>
>>>>>>>> ---
>>>>>>>> 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
>>

2021-11-30 18:45:41

[permalink] [raw]

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

Am Montag, 29. November 2021, 02:40:06 CET schrieb [email protected]:
> From: Wei Fu <[email protected]>
>
> 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 <[email protected]>
> Co-developed-by: Guo Ren <[email protected]>
> Signed-off-by: Guo Ren <[email protected]>
> Cc: Anup Patel <[email protected]>
> Cc: Palmer Dabbelt <[email protected]>
> Cc: Rob Herring <[email protected]>
> ---
> 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
>

2021-11-30 18:46:32

[permalink] [raw]

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

Am Montag, 29. November 2021, 02:40:07 CET schrieb [email protected]:
> From: Wei Fu <[email protected]>
>
> 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 <[email protected]>
> Co-developed-by: Liu Shaohua <[email protected]>
> Signed-off-by: Liu Shaohua <[email protected]>
> Co-developed-by: Guo Ren <[email protected]>
> Signed-off-by: Guo Ren <[email protected]>
> Cc: Palmer Dabbelt <[email protected]>
> Cc: Christoph Hellwig <[email protected]>
> Cc: Anup Patel <[email protected]>
> Cc: Arnd Bergmann <[email protected]>
> Cc: Atish Patra <[email protected]>
> Cc: Drew Fustini <[email protected]>
> Cc: Wei Fu <[email protected]>
> Cc: Wei Wu <[email protected]>
> Cc: Chen-Yu Tsai <[email protected]>
> Cc: Maxime Ripard <[email protected]>
> Cc: Daniel Lustig <[email protected]>
> Cc: Greg Favor <[email protected]>
> Cc: Andrea Mondelli <[email protected]>
> Cc: Jonathan Behrens <[email protected]>
> Cc: Xinhaoqu (Freddie) <[email protected]>
> Cc: Bill Huffman <[email protected]>
> Cc: Nick Kossifidis <[email protected]>
> Cc: Allen Baum <[email protected]>
> Cc: Josh Scheid <[email protected]>
> Cc: Richard Trauben <[email protected]>
> ---
> 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
>

2021-12-01 01:22:02

[permalink] [raw]

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

On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <[email protected]> wrote:
>
> On 30 Nov 2021, at 15:01, Philipp Tomsich <[email protected]> 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 <[email protected]> wrote:
> >>
> >> On 30 Nov 2021, at 13:27, Heiko Stübner <[email protected]> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke:
> >>>> On 30 Nov 2021, at 12:07, Heiko Stübner <[email protected]> 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, [email protected] wrote:
> >>>>>>>> From: Wei Fu <[email protected]>
> >>>>>>>>
> >>>>>>>> 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 <[email protected]>
> >>>>>>>> Co-developed-by: Guo Ren <[email protected]>
> >>>>>>>> Signed-off-by: Guo Ren <[email protected]>
> >>>>>>>> Cc: Anup Patel <[email protected]>
> >>>>>>>> Cc: Palmer Dabbelt <[email protected]>
> >>>>>>>> Cc: Rob Herring <[email protected]>
> >>>>>>>> ---
> >>>>>>>> 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
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-riscv

--
Regards,
Atish

2021-12-01 02:59:05

by Wei Fu

[permalink] [raw]

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

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 <[email protected]> wrote:
>
> Am Montag, 29. November 2021, 02:40:06 CET schrieb [email protected]:
> > From: Wei Fu <[email protected]>
> >
> > 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 <[email protected]>
> > Co-developed-by: Guo Ren <[email protected]>
> > Signed-off-by: Guo Ren <[email protected]>
> > Cc: Anup Patel <[email protected]>
> > Cc: Palmer Dabbelt <[email protected]>
> > Cc: Rob Herring <[email protected]>
> > ---
> > 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
> >
>
>
>
>

2021-12-01 03:00:50

by Wei Fu

[permalink] [raw]

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

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

On Wed, Dec 1, 2021 at 2:46 AM Heiko Stübner <[email protected]> wrote:
>
> Am Montag, 29. November 2021, 02:40:07 CET schrieb [email protected]:
> > From: Wei Fu <[email protected]>
> >
> > 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 <[email protected]>
> > Co-developed-by: Liu Shaohua <[email protected]>
> > Signed-off-by: Liu Shaohua <[email protected]>
> > Co-developed-by: Guo Ren <[email protected]>
> > Signed-off-by: Guo Ren <[email protected]>
> > Cc: Palmer Dabbelt <[email protected]>
> > Cc: Christoph Hellwig <[email protected]>
> > Cc: Anup Patel <[email protected]>
> > Cc: Arnd Bergmann <[email protected]>
> > Cc: Atish Patra <[email protected]>
> > Cc: Drew Fustini <[email protected]>
> > Cc: Wei Fu <[email protected]>
> > Cc: Wei Wu <[email protected]>
> > Cc: Chen-Yu Tsai <[email protected]>
> > Cc: Maxime Ripard <[email protected]>
> > Cc: Daniel Lustig <[email protected]>
> > Cc: Greg Favor <[email protected]>
> > Cc: Andrea Mondelli <[email protected]>
> > Cc: Jonathan Behrens <[email protected]>
> > Cc: Xinhaoqu (Freddie) <[email protected]>
> > Cc: Bill Huffman <[email protected]>
> > Cc: Nick Kossifidis <[email protected]>
> > Cc: Allen Baum <[email protected]>
> > Cc: Josh Scheid <[email protected]>
> > Cc: Richard Trauben <[email protected]>
> > ---
> > 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
> >
>
>
>
>

2021-12-01 03:03:48

by Wei Fu

[permalink] [raw]

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

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 <[email protected]> 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 <[email protected]> wrote:
> >
> > From: Wei Fu <[email protected]>
> >
> > 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 <[email protected]>
> > Co-developed-by: Liu Shaohua <[email protected]>
> > Signed-off-by: Liu Shaohua <[email protected]>
> > Co-developed-by: Guo Ren <[email protected]>
> > Signed-off-by: Guo Ren <[email protected]>
> > Cc: Palmer Dabbelt <[email protected]>
> > Cc: Christoph Hellwig <[email protected]>
> > Cc: Anup Patel <[email protected]>
> > Cc: Arnd Bergmann <[email protected]>
> > Cc: Atish Patra <[email protected]>
> > Cc: Drew Fustini <[email protected]>
> > Cc: Wei Fu <[email protected]>
> > Cc: Wei Wu <[email protected]>
> > Cc: Chen-Yu Tsai <[email protected]>
> > Cc: Maxime Ripard <[email protected]>
> > Cc: Daniel Lustig <[email protected]>
> > Cc: Greg Favor <[email protected]>
> > Cc: Andrea Mondelli <[email protected]>
> > Cc: Jonathan Behrens <[email protected]>
> > Cc: Xinhaoqu (Freddie) <[email protected]>
> > Cc: Bill Huffman <[email protected]>
> > Cc: Nick Kossifidis <[email protected]>
> > Cc: Allen Baum <[email protected]>
> > Cc: Josh Scheid <[email protected]>
> > Cc: Richard Trauben <[email protected]>
> > ---
> > 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/
>

2021-12-01 03:09:46

by Tsukasa OI

[permalink] [raw]

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

On 2021/12/01 10:21, Atish Patra wrote:
> On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <[email protected]> wrote:
>>
>> On 30 Nov 2021, at 15:01, Philipp Tomsich <[email protected]> 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 <[email protected]> wrote:
>>>>
>>>> On 30 Nov 2021, at 13:27, Heiko Stübner <[email protected]> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke:
>>>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <[email protected]> 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, [email protected] wrote:
>>>>>>>>>> From: Wei Fu <[email protected]>
>>>>>>>>>>
>>>>>>>>>> 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 <[email protected]>
>>>>>>>>>> Co-developed-by: Guo Ren <[email protected]>
>>>>>>>>>> Signed-off-by: Guo Ren <[email protected]>
>>>>>>>>>> Cc: Anup Patel <[email protected]>
>>>>>>>>>> Cc: Palmer Dabbelt <[email protected]>
>>>>>>>>>> Cc: Rob Herring <[email protected]>
>>>>>>>>>> ---
>>>>>>>>>> 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
>> [email protected]
>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>
>
>
> --
> Regards,
> Atish
>
> _______________________________________________
> linux-riscv mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-riscv
>

2021-12-01 05:12:24

by Wei Fu

[permalink] [raw]

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

Hi, Jisheng Zhang,

On Mon, Nov 29, 2021 at 9:44 PM Jisheng Zhang <[email protected]> wrote:
>
> On Mon, 29 Nov 2021 09:40:07 +0800
> [email protected] wrote:
>
> > From: Wei Fu <[email protected]>
> >
> > 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 <[email protected]>
> > Co-developed-by: Liu Shaohua <[email protected]>
> > Signed-off-by: Liu Shaohua <[email protected]>
> > Co-developed-by: Guo Ren <[email protected]>
> > Signed-off-by: Guo Ren <[email protected]>
> > Cc: Palmer Dabbelt <[email protected]>
> > Cc: Christoph Hellwig <[email protected]>
> > Cc: Anup Patel <[email protected]>
> > Cc: Arnd Bergmann <[email protected]>
> > Cc: Atish Patra <[email protected]>
> > Cc: Drew Fustini <[email protected]>
> > Cc: Wei Fu <[email protected]>
> > Cc: Wei Wu <[email protected]>
> > Cc: Chen-Yu Tsai <[email protected]>
> > Cc: Maxime Ripard <[email protected]>
> > Cc: Daniel Lustig <[email protected]>
> > Cc: Greg Favor <[email protected]>
> > Cc: Andrea Mondelli <[email protected]>
> > Cc: Jonathan Behrens <[email protected]>
> > Cc: Xinhaoqu (Freddie) <[email protected]>
> > Cc: Bill Huffman <[email protected]>
> > Cc: Nick Kossifidis <[email protected]>
> > Cc: Allen Baum <[email protected]>
> > Cc: Josh Scheid <[email protected]>
> > Cc: Richard Trauben <[email protected]>
> > ---
> > 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
>

2021-12-01 06:19:06

by Anup Patel

[permalink] [raw]

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

On Wed, Dec 1, 2021 at 10:35 AM Wei Fu <[email protected]> wrote:
>
> Hi, Jisheng Zhang,
>
> On Mon, Nov 29, 2021 at 9:44 PM Jisheng Zhang <[email protected]> wrote:
> >
> > On Mon, 29 Nov 2021 09:40:07 +0800
> > [email protected] wrote:
> >
> > > From: Wei Fu <[email protected]>
> > >
> > > 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 <[email protected]>
> > > Co-developed-by: Liu Shaohua <[email protected]>
> > > Signed-off-by: Liu Shaohua <[email protected]>
> > > Co-developed-by: Guo Ren <[email protected]>
> > > Signed-off-by: Guo Ren <[email protected]>
> > > Cc: Palmer Dabbelt <[email protected]>
> > > Cc: Christoph Hellwig <[email protected]>
> > > Cc: Anup Patel <[email protected]>
> > > Cc: Arnd Bergmann <[email protected]>
> > > Cc: Atish Patra <[email protected]>
> > > Cc: Drew Fustini <[email protected]>
> > > Cc: Wei Fu <[email protected]>
> > > Cc: Wei Wu <[email protected]>
> > > Cc: Chen-Yu Tsai <[email protected]>
> > > Cc: Maxime Ripard <[email protected]>
> > > Cc: Daniel Lustig <[email protected]>
> > > Cc: Greg Favor <[email protected]>
> > > Cc: Andrea Mondelli <[email protected]>
> > > Cc: Jonathan Behrens <[email protected]>
> > > Cc: Xinhaoqu (Freddie) <[email protected]>
> > > Cc: Bill Huffman <[email protected]>
> > > Cc: Nick Kossifidis <[email protected]>
> > > Cc: Allen Baum <[email protected]>
> > > Cc: Josh Scheid <[email protected]>
> > > Cc: Richard Trauben <[email protected]>
> > > ---
> > > 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
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-riscv

2021-12-01 08:15:33

[permalink] [raw]

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

On Tue, Nov 30, 2021 at 7:06 PM Tsukasa OI <[email protected]> wrote:
>
> On 2021/12/01 10:21, Atish Patra wrote:
> > On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <[email protected]> wrote:
> >>
> >> On 30 Nov 2021, at 15:01, Philipp Tomsich <[email protected]> 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 <[email protected]> wrote:
> >>>>
> >>>> On 30 Nov 2021, at 13:27, Heiko Stübner <[email protected]> wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke:
> >>>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <[email protected]> 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, [email protected] wrote:
> >>>>>>>>>> From: Wei Fu <[email protected]>
> >>>>>>>>>>
> >>>>>>>>>> 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 <[email protected]>
> >>>>>>>>>> Co-developed-by: Guo Ren <[email protected]>
> >>>>>>>>>> Signed-off-by: Guo Ren <[email protected]>
> >>>>>>>>>> Cc: Anup Patel <[email protected]>
> >>>>>>>>>> Cc: Palmer Dabbelt <[email protected]>
> >>>>>>>>>> Cc: Rob Herring <[email protected]>
> >>>>>>>>>> ---
> >>>>>>>>>> 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
> >> [email protected]
> >> http://lists.infradead.org/mailman/listinfo/linux-riscv
> >
> >
> >
> > --
> > Regards,
> > Atish
> >
> > _______________________________________________
> > linux-riscv mailing list
> > [email protected]
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
> >

--
Regards,
Atish

2021-12-01 08:30:37

[permalink] [raw]

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

Am Mittwoch, 1. Dezember 2021, 09:15:18 CET schrieb Atish Patra:
> On Tue, Nov 30, 2021 at 7:06 PM Tsukasa OI <[email protected]> wrote:
> >
> > On 2021/12/01 10:21, Atish Patra wrote:
> > > On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <[email protected]> wrote:
> > >>
> > >> On 30 Nov 2021, at 15:01, Philipp Tomsich <[email protected]> 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 <[email protected]> wrote:
> > >>>>
> > >>>> On 30 Nov 2021, at 13:27, Heiko Stübner <[email protected]> wrote:
> > >>>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke:
> > >>>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <[email protected]> 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, [email protected] wrote:
> > >>>>>>>>>> From: Wei Fu <[email protected]>
> > >>>>>>>>>>
> > >>>>>>>>>> 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 <[email protected]>
> > >>>>>>>>>> Co-developed-by: Guo Ren <[email protected]>
> > >>>>>>>>>> Signed-off-by: Guo Ren <[email protected]>
> > >>>>>>>>>> Cc: Anup Patel <[email protected]>
> > >>>>>>>>>> Cc: Palmer Dabbelt <[email protected]>
> > >>>>>>>>>> Cc: Rob Herring <[email protected]>
> > >>>>>>>>>> ---
> > >>>>>>>>>> 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
> > >> [email protected]
> > >> http://lists.infradead.org/mailman/listinfo/linux-riscv
> > >
> > >
> > >
> > > --
> > > Regards,
> > > Atish
> > >
> > > _______________________________________________
> > > linux-riscv mailing list
> > > [email protected]
> > > http://lists.infradead.org/mailman/listinfo/linux-riscv
> > >
>
>
>
>

2021-12-01 10:21:17

[permalink] [raw]

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

Am Mittwoch, 1. Dezember 2021, 09:41:48 CET schrieb atish patra:
> On Wed, Dec 1, 2021 at 12:30 AM Heiko Stübner <[email protected]> wrote:
>
> > Am Mittwoch, 1. Dezember 2021, 09:15:18 CET schrieb Atish Patra:
> > > On Tue, Nov 30, 2021 at 7:06 PM Tsukasa OI <[email protected]>
> > wrote:
> > > >
> > > > On 2021/12/01 10:21, Atish Patra wrote:
> > > > > On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <[email protected]>
> > wrote:
> > > > >>
> > > > >> On 30 Nov 2021, at 15:01, Philipp Tomsich <[email protected]>
> > 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 <[email protected]>
> > wrote:
> > > > >>>>
> > > > >>>> On 30 Nov 2021, at 13:27, Heiko Stübner <[email protected]> wrote:
> > > > >>>>>
> > > > >>>>> Hi,
> > > > >>>>>
> > > > >>>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica
> > Clarke:
> > > > >>>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <[email protected]>
> > 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, [email protected] wrote:
> > > > >>>>>>>>>> From: Wei Fu <[email protected]>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> 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 <[email protected]>
> > > > >>>>>>>>>> Co-developed-by: Guo Ren <[email protected]>
> > > > >>>>>>>>>> Signed-off-by: Guo Ren <[email protected]>
> > > > >>>>>>>>>> Cc: Anup Patel <[email protected]>
> > > > >>>>>>>>>> Cc: Palmer Dabbelt <[email protected]>
> > > > >>>>>>>>>> Cc: Rob Herring <[email protected]>
> > > > >>>>>>>>>> ---
> > > > >>>>>>>>>> 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
> > > > >> [email protected]
> > > > >> http://lists.infradead.org/mailman/listinfo/linux-riscv
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Regards,
> > > > > Atish
> > > > >
> > > > > _______________________________________________
> > > > > linux-riscv mailing list
> > > > > [email protected]
> > > > > http://lists.infradead.org/mailman/listinfo/linux-riscv
> > > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>

2021-12-01 11:05:19

by Philipp Tomsich

[permalink] [raw]

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

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 <[email protected]> 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 <[email protected]> wrote:
> >
> > > Am Mittwoch, 1. Dezember 2021, 09:15:18 CET schrieb Atish Patra:
> > > > On Tue, Nov 30, 2021 at 7:06 PM Tsukasa OI <[email protected]>
> > > wrote:
> > > > >
> > > > > On 2021/12/01 10:21, Atish Patra wrote:
> > > > > > On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <[email protected]>
> > > wrote:
> > > > > >>
> > > > > >> On 30 Nov 2021, at 15:01, Philipp Tomsich <[email protected]>
> > > 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 <[email protected]>
> > > wrote:
> > > > > >>>>
> > > > > >>>> On 30 Nov 2021, at 13:27, Heiko Stübner <[email protected]> wrote:
> > > > > >>>>>
> > > > > >>>>> Hi,
> > > > > >>>>>
> > > > > >>>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica
> > > Clarke:
> > > > > >>>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <[email protected]>
> > > 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, [email protected] wrote:
> > > > > >>>>>>>>>> From: Wei Fu <[email protected]>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> 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 <[email protected]>
> > > > > >>>>>>>>>> Co-developed-by: Guo Ren <[email protected]>
> > > > > >>>>>>>>>> Signed-off-by: Guo Ren <[email protected]>
> > > > > >>>>>>>>>> Cc: Anup Patel <[email protected]>
> > > > > >>>>>>>>>> Cc: Palmer Dabbelt <[email protected]>
> > > > > >>>>>>>>>> Cc: Rob Herring <[email protected]>
> > > > > >>>>>>>>>> ---
> > > > > >>>>>>>>>> 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
> > > > > >> [email protected]
> > > > > >> http://lists.infradead.org/mailman/listinfo/linux-riscv
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Regards,
> > > > > > Atish
> > > > > >
> > > > > > _______________________________________________
> > > > > > linux-riscv mailing list
> > > > > > [email protected]
> > > > > > http://lists.infradead.org/mailman/listinfo/linux-riscv
> > > > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> >
>
>
>
>

2021-12-01 13:28:29

[permalink] [raw]

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

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 <[email protected]> wrote:
> >
> > On 30 Nov 2021, at 15:01, Philipp Tomsich <[email protected]> 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 <[email protected]> wrote:
> > >>
> > >> On 30 Nov 2021, at 13:27, Heiko Stübner <[email protected]> wrote:
> > >>>
> > >>> Hi,
> > >>>
> > >>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke:
> > >>>> On 30 Nov 2021, at 12:07, Heiko Stübner <[email protected]> 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, [email protected] wrote:
> > >>>>>>>> From: Wei Fu <[email protected]>
> > >>>>>>>>
> > >>>>>>>> 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 <[email protected]>
> > >>>>>>>> Co-developed-by: Guo Ren <[email protected]>
> > >>>>>>>> Signed-off-by: Guo Ren <[email protected]>
> > >>>>>>>> Cc: Anup Patel <[email protected]>
> > >>>>>>>> Cc: Palmer Dabbelt <[email protected]>
> > >>>>>>>> Cc: Rob Herring <[email protected]>
> > >>>>>>>> ---
> > >>>>>>>> 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
> > [email protected]
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
>
>
>
> --
> Regards,
> Atish
>

2021-12-01 13:38:11

by Jisheng Zhang

[permalink] [raw]

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

On Wed, 1 Dec 2021 11:48:44 +0530
Anup Patel <[email protected]> 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

2021-12-01 13:39:20

[permalink] [raw]

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

On 1 Dec 2021, at 11:05, Philipp Tomsich <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote:
>>>
>>>> Am Mittwoch, 1. Dezember 2021, 09:15:18 CET schrieb Atish Patra:
>>>>> On Tue, Nov 30, 2021 at 7:06 PM Tsukasa OI <[email protected]>
>>>> wrote:
>>>>>>
>>>>>> On 2021/12/01 10:21, Atish Patra wrote:
>>>>>>> On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <[email protected]>
>>>> wrote:
>>>>>>>>
>>>>>>>> On 30 Nov 2021, at 15:01, Philipp Tomsich <[email protected]>
>>>> 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 <[email protected]>
>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> On 30 Nov 2021, at 13:27, Heiko Stübner <[email protected]> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica
>>>> Clarke:
>>>>>>>>>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <[email protected]>
>>>> 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, [email protected] wrote:
>>>>>>>>>>>>>>>> From: Wei Fu <[email protected]>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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 <[email protected]>
>>>>>>>>>>>>>>>> Co-developed-by: Guo Ren <[email protected]>
>>>>>>>>>>>>>>>> Signed-off-by: Guo Ren <[email protected]>
>>>>>>>>>>>>>>>> Cc: Anup Patel <[email protected]>
>>>>>>>>>>>>>>>> Cc: Palmer Dabbelt <[email protected]>
>>>>>>>>>>>>>>>> Cc: Rob Herring <[email protected]>
>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>> 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
>>>>>>>> [email protected]
>>>>>>>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>> Atish
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> linux-riscv mailing list
>>>>>>> [email protected]
>>>>>>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>

2021-12-02 01:31:28

by Tsukasa OI

[permalink] [raw]

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

On 2021/12/01 17:15, Atish Patra wrote:
> On Tue, Nov 30, 2021 at 7:06 PM Tsukasa OI <[email protected]> wrote:
>>
>> On 2021/12/01 10:21, Atish Patra wrote:
>>> On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <[email protected]> wrote:
>>>>
>>>> On 30 Nov 2021, at 15:01, Philipp Tomsich <[email protected]> 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 <[email protected]> wrote:
>>>>>>
>>>>>> On 30 Nov 2021, at 13:27, Heiko Stübner <[email protected]> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke:
>>>>>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <[email protected]> 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, [email protected] wrote:
>>>>>>>>>>>> From: Wei Fu <[email protected]>
>>>>>>>>>>>>
>>>>>>>>>>>> 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 <[email protected]>
>>>>>>>>>>>> Co-developed-by: Guo Ren <[email protected]>
>>>>>>>>>>>> Signed-off-by: Guo Ren <[email protected]>
>>>>>>>>>>>> Cc: Anup Patel <[email protected]>
>>>>>>>>>>>> Cc: Palmer Dabbelt <[email protected]>
>>>>>>>>>>>> Cc: Rob Herring <[email protected]>
>>>>>>>>>>>> ---
>>>>>>>>>>>> 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
>>>> [email protected]
>>>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Atish
>>>
>>> _______________________________________________
>>> linux-riscv mailing list
>>> [email protected]
>>> http://lists.infradead.org/mailman/listinfo/linux-riscv
>>>
>
>
>

2021-12-02 01:55:40

[permalink] [raw]

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

On Wed, Dec 1, 2021 at 5:31 PM Tsukasa OI <[email protected]> wrote:
>
> On 2021/12/01 17:15, Atish Patra wrote:
> > On Tue, Nov 30, 2021 at 7:06 PM Tsukasa OI <[email protected]> wrote:
> >>
> >> On 2021/12/01 10:21, Atish Patra wrote:
> >>> On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <[email protected]> wrote:
> >>>>
> >>>> On 30 Nov 2021, at 15:01, Philipp Tomsich <[email protected]> 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 <[email protected]> wrote:
> >>>>>>
> >>>>>> On 30 Nov 2021, at 13:27, Heiko Stübner <[email protected]> wrote:
> >>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke:
> >>>>>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <[email protected]> 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, [email protected] wrote:
> >>>>>>>>>>>> From: Wei Fu <[email protected]>
> >>>>>>>>>>>>
> >>>>>>>>>>>> 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 <[email protected]>
> >>>>>>>>>>>> Co-developed-by: Guo Ren <[email protected]>
> >>>>>>>>>>>> Signed-off-by: Guo Ren <[email protected]>
> >>>>>>>>>>>> Cc: Anup Patel <[email protected]>
> >>>>>>>>>>>> Cc: Palmer Dabbelt <[email protected]>
> >>>>>>>>>>>> Cc: Rob Herring <[email protected]>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>> 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
> >>>> [email protected]
> >>>> http://lists.infradead.org/mailman/listinfo/linux-riscv
> >>>
> >>>
> >>>
> >>> --
> >>> Regards,
> >>> Atish
> >>>
> >>> _______________________________________________
> >>> linux-riscv mailing list
> >>> [email protected]
> >>> http://lists.infradead.org/mailman/listinfo/linux-riscv
> >>>
> >
> >
> >

--
Regards,
Atish

2021-12-02 01:59:52