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(__riscv_svpbmt) as _PAGE_DMA_MASK/IO/NC for
pgprot_noncached (&writecombine) in pgtable.h.
We also add _PAGE_CHG_MASK to filter PFN than before.
Enable it in devicetree - (Add "mmu-supports-svpbmt" in cpu node)
- mmu-supports-svpbmt
Wei Fu (2):
dt-bindings: riscv: add mmu-supports-svpbmt for Svpbmt
riscv: add RISC-V Svpbmt extension supports
.../devicetree/bindings/riscv/cpus.yaml | 5 +++
arch/riscv/include/asm/fixmap.h | 2 +-
arch/riscv/include/asm/pgtable-64.h | 8 ++--
arch/riscv/include/asm/pgtable-bits.h | 41 ++++++++++++++++++-
arch/riscv/include/asm/pgtable.h | 39 ++++++++++++++----
arch/riscv/kernel/cpufeature.c | 32 +++++++++++++++
arch/riscv/mm/init.c | 5 +++
7 files changed, 117 insertions(+), 15 deletions(-)
--
2.25.4
From: Wei Fu <[email protected]>
Previous patch has added svpbmt in arch/riscv and changed the
DT mmu-type. 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 | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
index e534f6a7cfa1..76f324d85e12 100644
--- a/Documentation/devicetree/bindings/riscv/cpus.yaml
+++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
@@ -59,6 +59,11 @@ properties:
- riscv,sv48
- riscv,none
+ mmu-supports-svpbmt:
+ description:
+ Describes the CPU's mmu-supports-svpbmt support
+ $ref: '/schemas/types.yaml#/definitions/phandle'
+
riscv,isa:
description:
Identifies the specific RISC-V instruction set architecture
--
2.25.4
On Mon, Oct 25, 2021 at 12:06 PM <[email protected]> wrote:
>
> From: Wei Fu <[email protected]>
>
> Previous patch has added svpbmt in arch/riscv and changed the
> DT mmu-type. 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 | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> index e534f6a7cfa1..76f324d85e12 100644
> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> @@ -59,6 +59,11 @@ properties:
> - riscv,sv48
> - riscv,none
>
> + mmu-supports-svpbmt:
We need a "type: boolean" here.
ref: Documentation/devicetree/bindings/serial/8250.yaml
used-by-rtas:
type: boolean
description: |
Set to indicate that the port is in use by the OpenFirmware RTAS and
should not be registered.
> + description:
> + Describes the CPU's mmu-supports-svpbmt support
> + $ref: '/schemas/types.yaml#/definitions/phandle'
> +
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
On Sun, 24 Oct 2021 21:06:05 PDT (-0700), [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
Do you have a pointer to the spec that contains these? I'm specifically
worried about these page-based attributes being elided when paging is
off (ie, M-mode), which has caused issues in systems I've worked with in
the past. I'm assuming there's something related to this in the specs,
but I'm worried we'll need some sort of ack from M-mode that it's been
setup to work that way. One could imagine an MPRV-like approach
working, but I don't see enough in the old specs and I'm having trouble
figuring out where the canonical version of this lives.
> 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(__riscv_svpbmt) as _PAGE_DMA_MASK/IO/NC for
> pgprot_noncached (&writecombine) in pgtable.h.
> We also add _PAGE_CHG_MASK to filter PFN than before.
>
> Enable it in devicetree - (Add "mmu-supports-svpbmt" in cpu node)
> - mmu-supports-svpbmt
Maybe this is enough of an ack, but we'll need to have some pretty
specific documentation if that's the case. It's not described that way
in the docs right now, they just talk about CPU support (IMO we could
probe that with a trap, but I'm fine with the DT entry as it's a bit
simpler).
> Wei Fu (2):
> dt-bindings: riscv: add mmu-supports-svpbmt for Svpbmt
> riscv: add RISC-V Svpbmt extension supports
>
> .../devicetree/bindings/riscv/cpus.yaml | 5 +++
> arch/riscv/include/asm/fixmap.h | 2 +-
> arch/riscv/include/asm/pgtable-64.h | 8 ++--
> arch/riscv/include/asm/pgtable-bits.h | 41 ++++++++++++++++++-
> arch/riscv/include/asm/pgtable.h | 39 ++++++++++++++----
> arch/riscv/kernel/cpufeature.c | 32 +++++++++++++++
> arch/riscv/mm/init.c | 5 +++
> 7 files changed, 117 insertions(+), 15 deletions(-)
On 10/27/21 02:12, Palmer Dabbelt wrote:
> On Sun, 24 Oct 2021 21:06:05 PDT (-0700), [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
>
> Do you have a pointer to the spec that contains these? I'm specifically
> worried about these page-based attributes being elided when paging is
> off (ie, M-mode), which has caused issues in systems I've worked with in
> the past. I'm assuming there's something related to this in the specs,
> but I'm worried we'll need some sort of ack from M-mode that it's been
> setup to work that way. One could imagine an MPRV-like approach
> working, but I don't see enough in the old specs and I'm having trouble
> figuring out where the canonical version of this lives.
The draft version of the spec is available in chapter 6, p 87 of
https://raw.githubusercontent.com/riscv/virtual-memory/main/specs/663-Svpbmt.pdf
According to
https://groups.google.com/a/groups.riscv.org/g/isa-dev/c/nOrD9t9ImEw/m/tstjm4QbAAAJ
review has started Sep 17th.
Best regards
Heinrich
>
>> 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(__riscv_svpbmt) as _PAGE_DMA_MASK/IO/NC for
>> pgprot_noncached (&writecombine) in pgtable.h.
>> We also add _PAGE_CHG_MASK to filter PFN than before.
>>
>> Enable it in devicetree - (Add "mmu-supports-svpbmt" in cpu node)
>> - mmu-supports-svpbmt
>
> Maybe this is enough of an ack, but we'll need to have some pretty
> specific documentation if that's the case. It's not described that way
> in the docs right now, they just talk about CPU support (IMO we could
> probe that with a trap, but I'm fine with the DT entry as it's a bit
> simpler).
>
>> Wei Fu (2):
>> dt-bindings: riscv: add mmu-supports-svpbmt for Svpbmt
>> riscv: add RISC-V Svpbmt extension supports
>>
>> .../devicetree/bindings/riscv/cpus.yaml | 5 +++
>> arch/riscv/include/asm/fixmap.h | 2 +-
>> arch/riscv/include/asm/pgtable-64.h | 8 ++--
>> arch/riscv/include/asm/pgtable-bits.h | 41 ++++++++++++++++++-
>> arch/riscv/include/asm/pgtable.h | 39 ++++++++++++++----
>> arch/riscv/kernel/cpufeature.c | 32 +++++++++++++++
>> arch/riscv/mm/init.c | 5 +++
>> 7 files changed, 117 insertions(+), 15 deletions(-)
On Wed, Oct 27, 2021 at 8:12 AM Palmer Dabbelt <[email protected]> wrote:
>
> On Sun, 24 Oct 2021 21:06:05 PDT (-0700), [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
>
> Do you have a pointer to the spec that contains these? I'm specifically
> worried about these page-based attributes being elided when paging is
> off (ie, M-mode), which has caused issues in systems I've worked with in
> the past.
Don't worry about that, I've compiled the Linux with the patch and
below modification in k210_nommu_defconfig. Passed
diff --git a/arch/riscv/include/asm/pgtable-bits.h
b/arch/riscv/include/asm/pgtable-bits.h
index 3b38fe14f169..b4bb41337fdc 100644
--- a/arch/riscv/include/asm/pgtable-bits.h
+++ b/arch/riscv/include/asm/pgtable-bits.h
@@ -25,7 +25,7 @@
#define _PAGE_SOFT (1 << 8) /* Reserved for software */
#ifndef __ASSEMBLY__
-#ifdef CONFIG_64BIT
+#if defined(CONFIG_64BIT) && defined(CONFIG_MMU)
/*
* rv64 PTE format:
* | 63 | 62 61 | 60 54 | 53 10 | 9 8 | 7 | 6 | 5 | 4 |
3 | 2 | 1 | 0
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index d198eabe55d4..58639dfe5917 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -856,7 +856,7 @@ int __meminit vmemmap_populate(unsigned long
start, unsigned long end, int node,
}
#endif
-#ifdef CONFIG_64BIT
+#if defined(CONFIG_64BIT) && defined(CONFIG_MMU)
struct __riscv_svpbmt_struct __riscv_svpbmt __ro_after_init;
EXPORT_SYMBOL(__riscv_svpbmt);
So, I don't think the patch would affect M-mode nommu Linux.
To separate MMU & no-MMU clearly, I suggest fuwei add
#if defined(CONFIG_64BIT) && defined(CONFIG_MMU)
> I'm assuming there's something related to this in the specs,
> but I'm worried we'll need some sort of ack from M-mode that it's been
> setup to work that way. One could imagine an MPRV-like approach
> working, but I don't see enough in the old specs and I'm having trouble
> figuring out where the canonical version of this lives.
>
> > 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(__riscv_svpbmt) as _PAGE_DMA_MASK/IO/NC for
> > pgprot_noncached (&writecombine) in pgtable.h.
> > We also add _PAGE_CHG_MASK to filter PFN than before.
> >
> > Enable it in devicetree - (Add "mmu-supports-svpbmt" in cpu node)
> > - mmu-supports-svpbmt
>
> Maybe this is enough of an ack, but we'll need to have some pretty
> specific documentation if that's the case. It's not described that way
> in the docs right now, they just talk about CPU support (IMO we could
> probe that with a trap, but I'm fine with the DT entry as it's a bit
> simpler).
>
> > Wei Fu (2):
> > dt-bindings: riscv: add mmu-supports-svpbmt for Svpbmt
> > riscv: add RISC-V Svpbmt extension supports
> >
> > .../devicetree/bindings/riscv/cpus.yaml | 5 +++
> > arch/riscv/include/asm/fixmap.h | 2 +-
> > arch/riscv/include/asm/pgtable-64.h | 8 ++--
> > arch/riscv/include/asm/pgtable-bits.h | 41 ++++++++++++++++++-
> > arch/riscv/include/asm/pgtable.h | 39 ++++++++++++++----
> > arch/riscv/kernel/cpufeature.c | 32 +++++++++++++++
> > arch/riscv/mm/init.c | 5 +++
> > 7 files changed, 117 insertions(+), 15 deletions(-)
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
On Tue, Nov 02, 2021 at 10:07:58AM +0800, Guo Ren wrote:
>
> To separate MMU & no-MMU clearly, I suggest fuwei add
> #if defined(CONFIG_64BIT) && defined(CONFIG_MMU)
Actually - for documentation purposes a new CONFIG_RISCV_SVPBMT that
depends on 64BIT && MMU would probably much better as it clearly
documents the intent here.
Thx Christoph,
On Tue, Nov 2, 2021 at 1:59 PM Christoph Hellwig <[email protected]> wrote:
>
> On Tue, Nov 02, 2021 at 10:07:58AM +0800, Guo Ren wrote:
> >
> > To separate MMU & no-MMU clearly, I suggest fuwei add
> > #if defined(CONFIG_64BIT) && defined(CONFIG_MMU)
>
> Actually - for documentation purposes a new CONFIG_RISCV_SVPBMT that
> depends on 64BIT && MMU would probably much better as it clearly
> documents the intent here.
Okay
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
HI Guo， Christoph,
Thanks for your suggestion.
On Tue, Nov 2, 2021 at 4:51 PM Guo Ren <[email protected]> wrote:
>
> Thx Christoph,
>
> On Tue, Nov 2, 2021 at 1:59 PM Christoph Hellwig <[email protected]> wrote:
> >
> > On Tue, Nov 02, 2021 at 10:07:58AM +0800, Guo Ren wrote:
> > >
> > > To separate MMU & no-MMU clearly, I suggest fuwei add
> > > #if defined(CONFIG_64BIT) && defined(CONFIG_MMU)
> >
> > Actually - for documentation purposes a new CONFIG_RISCV_SVPBMT that
> > depends on 64BIT && MMU would probably much better as it clearly
> > documents the intent here.
> Okay
How about
config RISCV_SVPBMT
bool
depends on 64BIT && MMU
default y
>
>
> --
> Best Regards
> Guo Ren
>
> ML: https://lore.kernel.org/linux-csky/
>
On Sun, Nov 07, 2021 at 03:12:51PM +0800, Wei Fu wrote:
> How about
>
> config RISCV_SVPBMT
> bool
> depends on 64BIT && MMU
> default y
Yes. You can shorten this a bit more using def_bool if you want.
Hi Christoph,
On Mon, Nov 8, 2021 at 3:52 PM Christoph Hellwig <[email protected]> wrote:
>
> On Sun, Nov 07, 2021 at 03:12:51PM +0800, Wei Fu wrote:
> > How about
> >
> > config RISCV_SVPBMT
> > bool
> > depends on 64BIT && MMU
> > default y
>
> Yes. You can shorten this a bit more using def_bool if you want.
Sorry for the late reply, OK, fixing it now
>