* [PATCH V4 0/2] riscv: add RISC-V Svpbmt Standard Extension supports @ 2021-11-29 1:40 wefu 2021-11-29 1:40 ` [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt wefu ` (2 more replies) 0 siblings, 3 replies; 35+ messages in thread From: wefu @ 2021-11-29 1:40 UTC (permalink / raw) To: anup.patel, atishp04, palmer, guoren, christoph.muellner, philipp.tomsich, hch, liush, wefu, lazyparser, drew Cc: linux-riscv, linux-kernel, taiten.peng, aniket.ponkshe, heinrich.schuchardt, gordan.markus, guoren, arnd, wens, maxime, dlustig, gfavor, andrea.mondelli, behrensj, xinhaoqu, huffman, mick, allen.baum, jscheid, rtrauben From: Fu Wei <wefu@redhat.com> This patch follows the RISC-V standard Svpbmt extension in privilege spec to solve the non-coherent SOC DMA synchronization issues. The svpbmt PTE format: | 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 N MT RSW D A G U X W R V ^ Of the Reserved bits [63:54] in a leaf PTE, the bits [62:61] are used as the MT (aka MemType) field. This field specifies one of three memory types as shown in the following table: MemType RISC-V Description ---------- ------------------------------------------------ 00 - PMA Normal Cacheable, No change to implied PMA memory type 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory 11 - Rsvd Reserved for future standard use The standard protection_map[] needn't be modified because the "PMA" type keeps the highest bits zero. And the whole modification is limited in the arch/riscv/* and using a global variable(__svpbmt) as _PAGE_MASK/IO/NOCACHE for pgprot_noncached (&writecombine) in pgtable.h. We also add _PAGE_CHG_MASK to filter PFN than before. Enable it in devicetree - (Add "riscv,svpbmt" in the mmu of cpu node) - mmu: riscv,svpmbt Wei Fu (2): dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt riscv: add RISC-V Svpbmt extension supports .../devicetree/bindings/riscv/cpus.yaml | 10 +++++ arch/riscv/include/asm/fixmap.h | 2 +- arch/riscv/include/asm/pgtable-64.h | 21 ++++++++-- arch/riscv/include/asm/pgtable-bits.h | 39 ++++++++++++++++++- arch/riscv/include/asm/pgtable.h | 39 ++++++++++++++----- arch/riscv/kernel/cpufeature.c | 35 +++++++++++++++++ arch/riscv/mm/init.c | 5 +++ 7 files changed, 136 insertions(+), 15 deletions(-) -- 2.25.4 ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt 2021-11-29 1:40 [PATCH V4 0/2] riscv: add RISC-V Svpbmt Standard Extension supports wefu @ 2021-11-29 1:40 ` wefu 2021-11-29 8:54 ` Heinrich Schuchardt 2021-11-30 18:45 ` Heiko Stübner 2021-11-29 1:40 ` [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports wefu 2021-11-29 13:33 ` [PATCH V4 0/2] riscv: add RISC-V Svpbmt Standard Extension supports Jisheng Zhang 2 siblings, 2 replies; 35+ messages in thread From: wefu @ 2021-11-29 1:40 UTC (permalink / raw) To: anup.patel, atishp04, palmer, guoren, christoph.muellner, philipp.tomsich, hch, liush, wefu, lazyparser, drew Cc: linux-riscv, linux-kernel, taiten.peng, aniket.ponkshe, heinrich.schuchardt, gordan.markus, guoren, arnd, wens, maxime, dlustig, gfavor, andrea.mondelli, behrensj, xinhaoqu, huffman, mick, allen.baum, jscheid, rtrauben, Anup Patel, Rob Herring From: Wei Fu <wefu@redhat.com> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt" in the DT mmu node. Update dt-bindings related property here. Signed-off-by: Wei Fu <wefu@redhat.com> Co-developed-by: Guo Ren <guoren@kernel.org> Signed-off-by: Guo Ren <guoren@kernel.org> Cc: Anup Patel <anup@brainfault.org> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Rob Herring <robh+dt@kernel.org> --- Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml index aa5fb64d57eb..9ff9cbdd8a85 100644 --- a/Documentation/devicetree/bindings/riscv/cpus.yaml +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml @@ -63,6 +63,16 @@ properties: - riscv,sv48 - riscv,none + mmu: + description: + Describes the CPU's MMU Standard Extensions support. + These values originate from the RISC-V Privileged + Specification document, available from + https://riscv.org/specifications/ + $ref: '/schemas/types.yaml#/definitions/string' + enum: + - riscv,svpmbt + riscv,isa: description: Identifies the specific RISC-V instruction set architecture -- 2.25.4 ^ permalink raw reply related [flat|nested] 35+ messages in thread
* Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt 2021-11-29 1:40 ` [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt wefu @ 2021-11-29 8:54 ` Heinrich Schuchardt 2021-11-29 12:06 ` Heiko Stübner 2021-11-30 18:45 ` Heiko Stübner 1 sibling, 1 reply; 35+ messages in thread From: Heinrich Schuchardt @ 2021-11-29 8:54 UTC (permalink / raw) To: wefu Cc: linux-riscv, linux-kernel, taiten.peng, aniket.ponkshe, gordan.markus, guoren, arnd, wens, maxime, dlustig, gfavor, andrea.mondelli, behrensj, xinhaoqu, huffman, mick, allen.baum, jscheid, rtrauben, Anup Patel, Rob Herring, anup.patel, atishp04, palmer, guoren, christoph.muellner, philipp.tomsich, hch, liush, lazyparser, drew On 11/29/21 02:40, wefu@redhat.com wrote: > From: Wei Fu <wefu@redhat.com> > > Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt" > in the DT mmu node. Update dt-bindings related property here. > > Signed-off-by: Wei Fu <wefu@redhat.com> > Co-developed-by: Guo Ren <guoren@kernel.org> > Signed-off-by: Guo Ren <guoren@kernel.org> > Cc: Anup Patel <anup@brainfault.org> > Cc: Palmer Dabbelt <palmer@dabbelt.com> > Cc: Rob Herring <robh+dt@kernel.org> > --- > Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml > index aa5fb64d57eb..9ff9cbdd8a85 100644 > --- a/Documentation/devicetree/bindings/riscv/cpus.yaml > +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml > @@ -63,6 +63,16 @@ properties: > - riscv,sv48 > - riscv,none > > + mmu: Shouldn't we keep the items be in alphabetic order, i.e. mmu before mmu-type? > + description: > + Describes the CPU's MMU Standard Extensions support. > + These values originate from the RISC-V Privileged > + Specification document, available from > + https://riscv.org/specifications/ > + $ref: '/schemas/types.yaml#/definitions/string' > + enum: > + - riscv,svpmbt The privileged specification has multiple MMU related extensions: Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum? Best regards Heinrich > + > riscv,isa: > description: > Identifies the specific RISC-V instruction set architecture > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt 2021-11-29 8:54 ` Heinrich Schuchardt @ 2021-11-29 12:06 ` Heiko Stübner 2021-11-30 12:07 ` Heiko Stübner 0 siblings, 1 reply; 35+ messages in thread From: Heiko Stübner @ 2021-11-29 12:06 UTC (permalink / raw) To: wefu, linux-riscv Cc: linux-riscv, linux-kernel, taiten.peng, aniket.ponkshe, gordan.markus, guoren, arnd, wens, maxime, dlustig, gfavor, andrea.mondelli, behrensj, xinhaoqu, huffman, mick, allen.baum, jscheid, rtrauben, Anup Patel, Rob Herring, anup.patel, atishp04, palmer, guoren, christoph.muellner, philipp.tomsich, hch, liush, lazyparser, drew, Heinrich Schuchardt Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt: > On 11/29/21 02:40, wefu@redhat.com wrote: > > From: Wei Fu <wefu@redhat.com> > > > > Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt" > > in the DT mmu node. Update dt-bindings related property here. > > > > Signed-off-by: Wei Fu <wefu@redhat.com> > > Co-developed-by: Guo Ren <guoren@kernel.org> > > Signed-off-by: Guo Ren <guoren@kernel.org> > > Cc: Anup Patel <anup@brainfault.org> > > Cc: Palmer Dabbelt <palmer@dabbelt.com> > > Cc: Rob Herring <robh+dt@kernel.org> > > --- > > Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml > > index aa5fb64d57eb..9ff9cbdd8a85 100644 > > --- a/Documentation/devicetree/bindings/riscv/cpus.yaml > > +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml > > @@ -63,6 +63,16 @@ properties: > > - riscv,sv48 > > - riscv,none > > > > + mmu: > > Shouldn't we keep the items be in alphabetic order, i.e. mmu before > mmu-type? > > > + description: > > + Describes the CPU's MMU Standard Extensions support. > > + These values originate from the RISC-V Privileged > > + Specification document, available from > > + https://riscv.org/specifications/ > > + $ref: '/schemas/types.yaml#/definitions/string' > > + enum: > > + - riscv,svpmbt > > The privileged specification has multiple MMU related extensions: > Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum? I remember in some earlier version some way back there was the suggestion of using a sub-node instead and then adding boolean properties for the supported extensions. Aka something like mmu { riscv,svpbmt; }; Which I guess would be a lot nicer. Also right now there is string- comparison done on the code side, which would look way easier when just looking for booleans in the dt instead. Also isn't an enum a "one-of" selection, so wouldn't work directly for multiple extensions? Heiko > > Best regards > > Heinrich > > > + > > riscv,isa: > > description: > > Identifies the specific RISC-V instruction set architecture > > > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt 2021-11-29 12:06 ` Heiko Stübner @ 2021-11-30 12:07 ` Heiko Stübner 2021-11-30 13:17 ` Jessica Clarke 0 siblings, 1 reply; 35+ messages in thread From: Heiko Stübner @ 2021-11-30 12:07 UTC (permalink / raw) To: wefu, linux-riscv Cc: linux-riscv, linux-kernel, taiten.peng, aniket.ponkshe, gordan.markus, guoren, arnd, wens, maxime, dlustig, gfavor, andrea.mondelli, behrensj, xinhaoqu, huffman, mick, allen.baum, jscheid, rtrauben, Anup Patel, Rob Herring, anup.patel, atishp04, palmer, guoren, christoph.muellner, philipp.tomsich, hch, liush, lazyparser, drew, Heinrich Schuchardt, Heiko Stübner Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner: > Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt: > > On 11/29/21 02:40, wefu@redhat.com wrote: > > > From: Wei Fu <wefu@redhat.com> > > > > > > Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt" > > > in the DT mmu node. Update dt-bindings related property here. > > > > > > Signed-off-by: Wei Fu <wefu@redhat.com> > > > Co-developed-by: Guo Ren <guoren@kernel.org> > > > Signed-off-by: Guo Ren <guoren@kernel.org> > > > Cc: Anup Patel <anup@brainfault.org> > > > Cc: Palmer Dabbelt <palmer@dabbelt.com> > > > Cc: Rob Herring <robh+dt@kernel.org> > > > --- > > > Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++ > > > 1 file changed, 10 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml > > > index aa5fb64d57eb..9ff9cbdd8a85 100644 > > > --- a/Documentation/devicetree/bindings/riscv/cpus.yaml > > > +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml > > > @@ -63,6 +63,16 @@ properties: > > > - riscv,sv48 > > > - riscv,none > > > > > > + mmu: > > > > Shouldn't we keep the items be in alphabetic order, i.e. mmu before > > mmu-type? > > > > > + description: > > > + Describes the CPU's MMU Standard Extensions support. > > > + These values originate from the RISC-V Privileged > > > + Specification document, available from > > > + https://riscv.org/specifications/ > > > + $ref: '/schemas/types.yaml#/definitions/string' > > > + enum: > > > + - riscv,svpmbt > > > > The privileged specification has multiple MMU related extensions: > > Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum? > > I remember in some earlier version some way back there was the > suggestion of using a sub-node instead and then adding boolean > properties for the supported extensions. > > Aka something like > mmu { > riscv,svpbmt; > }; For the record, I'm talking about the mail from september https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/ So having a sub-node would make adding future extensions way nicer. > > Which I guess would be a lot nicer. Also right now there is string- > comparison done on the code side, which would look way easier > when just looking for booleans in the dt instead. > > Also isn't an enum a "one-of" selection, so wouldn't work directly > for multiple extensions? > > > Heiko > > > > > > Best regards > > > > Heinrich > > > > > + > > > riscv,isa: > > > description: > > > Identifies the specific RISC-V instruction set architecture > > > > > > > > > _______________________________________________ > > linux-riscv mailing list > > linux-riscv@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-riscv > > > > > > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt 2021-11-30 12:07 ` Heiko Stübner @ 2021-11-30 13:17 ` Jessica Clarke 2021-11-30 13:27 ` Heiko Stübner 0 siblings, 1 reply; 35+ messages in thread From: Jessica Clarke @ 2021-11-30 13:17 UTC (permalink / raw) To: Heiko Stübner Cc: Wei Fu, linux-riscv, linux-kernel@vger.kernel.org List, taiten.peng, aniket.ponkshe, gordan.markus, Guo Ren, arnd, wens, maxime, Dan Lustig, Greg Favor, andrea.mondelli, behrensj, xinhaoqu, huffman, Nick Kossifidis, Allen Baum, jscheid, rtrauben, Anup Patel, Rob Herring, Anup Patel, atishp04, Palmer Dabbelt, Guo Ren, Christoph Müllner, Philipp Tomsich, hch, liush, Wei Wu, drew, Heinrich Schuchardt On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote: > > Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner: >> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt: >>> On 11/29/21 02:40, wefu@redhat.com wrote: >>>> From: Wei Fu <wefu@redhat.com> >>>> >>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt" >>>> in the DT mmu node. Update dt-bindings related property here. >>>> >>>> Signed-off-by: Wei Fu <wefu@redhat.com> >>>> Co-developed-by: Guo Ren <guoren@kernel.org> >>>> Signed-off-by: Guo Ren <guoren@kernel.org> >>>> Cc: Anup Patel <anup@brainfault.org> >>>> Cc: Palmer Dabbelt <palmer@dabbelt.com> >>>> Cc: Rob Herring <robh+dt@kernel.org> >>>> --- >>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++ >>>> 1 file changed, 10 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml >>>> index aa5fb64d57eb..9ff9cbdd8a85 100644 >>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml >>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml >>>> @@ -63,6 +63,16 @@ properties: >>>> - riscv,sv48 >>>> - riscv,none >>>> >>>> + mmu: >>> >>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before >>> mmu-type? >>> >>>> + description: >>>> + Describes the CPU's MMU Standard Extensions support. >>>> + These values originate from the RISC-V Privileged >>>> + Specification document, available from >>>> + https://riscv.org/specifications/ >>>> + $ref: '/schemas/types.yaml#/definitions/string' >>>> + enum: >>>> + - riscv,svpmbt >>> >>> The privileged specification has multiple MMU related extensions: >>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum? >> >> I remember in some earlier version some way back there was the >> suggestion of using a sub-node instead and then adding boolean >> properties for the supported extensions. >> >> Aka something like >> mmu { >> riscv,svpbmt; >> }; > > For the record, I'm talking about the mail from september > https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/ > > So having a sub-node would make adding future extensions > way nicer. Svpbmt is just an ISA extension, and should be treated like any other. Let’s not invent two different ways of representing that in the device tree. Jess ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt 2021-11-30 13:17 ` Jessica Clarke @ 2021-11-30 13:27 ` Heiko Stübner 2021-11-30 13:59 ` Jessica Clarke 0 siblings, 1 reply; 35+ messages in thread From: Heiko Stübner @ 2021-11-30 13:27 UTC (permalink / raw) To: linux-riscv, Jessica Clarke Cc: Wei Fu, linux-riscv, linux-kernel@vger.kernel.org List, taiten.peng, aniket.ponkshe, gordan.markus, Guo Ren, arnd, wens, maxime, Dan Lustig, Greg Favor, andrea.mondelli, behrensj, xinhaoqu, huffman, Nick Kossifidis, Allen Baum, jscheid, rtrauben, Anup Patel, Rob Herring, Anup Patel, atishp04, Palmer Dabbelt, Guo Ren, Christoph Müllner, Philipp Tomsich, hch, liush, Wei Wu, drew, Heinrich Schuchardt Hi, Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke: > On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote: > > > > Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner: > >> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt: > >>> On 11/29/21 02:40, wefu@redhat.com wrote: > >>>> From: Wei Fu <wefu@redhat.com> > >>>> > >>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt" > >>>> in the DT mmu node. Update dt-bindings related property here. > >>>> > >>>> Signed-off-by: Wei Fu <wefu@redhat.com> > >>>> Co-developed-by: Guo Ren <guoren@kernel.org> > >>>> Signed-off-by: Guo Ren <guoren@kernel.org> > >>>> Cc: Anup Patel <anup@brainfault.org> > >>>> Cc: Palmer Dabbelt <palmer@dabbelt.com> > >>>> Cc: Rob Herring <robh+dt@kernel.org> > >>>> --- > >>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++ > >>>> 1 file changed, 10 insertions(+) > >>>> > >>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml > >>>> index aa5fb64d57eb..9ff9cbdd8a85 100644 > >>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml > >>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml > >>>> @@ -63,6 +63,16 @@ properties: > >>>> - riscv,sv48 > >>>> - riscv,none > >>>> > >>>> + mmu: > >>> > >>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before > >>> mmu-type? > >>> > >>>> + description: > >>>> + Describes the CPU's MMU Standard Extensions support. > >>>> + These values originate from the RISC-V Privileged > >>>> + Specification document, available from > >>>> + https://riscv.org/specifications/ > >>>> + $ref: '/schemas/types.yaml#/definitions/string' > >>>> + enum: > >>>> + - riscv,svpmbt > >>> > >>> The privileged specification has multiple MMU related extensions: > >>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum? > >> > >> I remember in some earlier version some way back there was the > >> suggestion of using a sub-node instead and then adding boolean > >> properties for the supported extensions. > >> > >> Aka something like > >> mmu { > >> riscv,svpbmt; > >> }; > > > > For the record, I'm talking about the mail from september > > https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/ > > > > So having a sub-node would make adding future extensions > > way nicer. > > Svpbmt is just an ISA extension, and should be treated like any other. > Let’s not invent two different ways of representing that in the device > tree. Heinrich asked how the other extensions should be handled (Svnapot, Svpbmt, Svinval), so what do you suggest to do with these? Thanks Heiko ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt 2021-11-30 13:27 ` Heiko Stübner @ 2021-11-30 13:59 ` Jessica Clarke 2021-11-30 15:01 ` Philipp Tomsich 0 siblings, 1 reply; 35+ messages in thread From: Jessica Clarke @ 2021-11-30 13:59 UTC (permalink / raw) To: Heiko Stübner Cc: linux-riscv, Wei Fu, linux-kernel@vger.kernel.org List, taiten.peng, aniket.ponkshe, gordan.markus, Guo Ren, arnd, wens, maxime, Dan Lustig, Greg Favor, andrea.mondelli, behrensj, xinhaoqu, huffman, Nick Kossifidis, Allen Baum, jscheid, rtrauben, Anup Patel, Rob Herring, Anup Patel, atishp04, Palmer Dabbelt, Guo Ren, Christoph Müllner, Philipp Tomsich, hch, liush, Wei Wu, drew, Heinrich Schuchardt On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote: > > Hi, > > Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke: >> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote: >>> >>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner: >>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt: >>>>> On 11/29/21 02:40, wefu@redhat.com wrote: >>>>>> From: Wei Fu <wefu@redhat.com> >>>>>> >>>>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt" >>>>>> in the DT mmu node. Update dt-bindings related property here. >>>>>> >>>>>> Signed-off-by: Wei Fu <wefu@redhat.com> >>>>>> Co-developed-by: Guo Ren <guoren@kernel.org> >>>>>> Signed-off-by: Guo Ren <guoren@kernel.org> >>>>>> Cc: Anup Patel <anup@brainfault.org> >>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com> >>>>>> Cc: Rob Herring <robh+dt@kernel.org> >>>>>> --- >>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++ >>>>>> 1 file changed, 10 insertions(+) >>>>>> >>>>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml >>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644 >>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml >>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml >>>>>> @@ -63,6 +63,16 @@ properties: >>>>>> - riscv,sv48 >>>>>> - riscv,none >>>>>> >>>>>> + mmu: >>>>> >>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before >>>>> mmu-type? >>>>> >>>>>> + description: >>>>>> + Describes the CPU's MMU Standard Extensions support. >>>>>> + These values originate from the RISC-V Privileged >>>>>> + Specification document, available from >>>>>> + https://riscv.org/specifications/ >>>>>> + $ref: '/schemas/types.yaml#/definitions/string' >>>>>> + enum: >>>>>> + - riscv,svpmbt >>>>> >>>>> The privileged specification has multiple MMU related extensions: >>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum? >>>> >>>> I remember in some earlier version some way back there was the >>>> suggestion of using a sub-node instead and then adding boolean >>>> properties for the supported extensions. >>>> >>>> Aka something like >>>> mmu { >>>> riscv,svpbmt; >>>> }; >>> >>> For the record, I'm talking about the mail from september >>> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/ >>> >>> So having a sub-node would make adding future extensions >>> way nicer. >> >> Svpbmt is just an ISA extension, and should be treated like any other. >> Let’s not invent two different ways of representing that in the device >> tree. > > Heinrich asked how the other extensions should be handled > (Svnapot, Svpbmt, Svinval), so what do you suggest to do with these? Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may not be a concrete plan for that yet, but that means you should speak with the people involved with such extensions and come up with something appropriate together. Jess ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt 2021-11-30 13:59 ` Jessica Clarke @ 2021-11-30 15:01 ` Philipp Tomsich 2021-11-30 16:12 ` Jessica Clarke 0 siblings, 1 reply; 35+ messages in thread From: Philipp Tomsich @ 2021-11-30 15:01 UTC (permalink / raw) To: Jessica Clarke Cc: Heiko Stübner, linux-riscv, Wei Fu, linux-kernel@vger.kernel.org List, taiten.peng, aniket.ponkshe, gordan.markus, Guo Ren, arnd, wens, maxime, Dan Lustig, Greg Favor, andrea.mondelli, behrensj, xinhaoqu, huffman, Nick Kossifidis, Allen Baum, jscheid, rtrauben, Anup Patel, Rob Herring, Anup Patel, atishp04, Palmer Dabbelt, Guo Ren, Christoph Müllner, hch, liush, Wei Wu, drew, Heinrich Schuchardt We did touch on this in our coordination call a few weeks ago: the grouping under mmu and the bool-entries were chosen because of their similarity to other extensions (i.e. for Zb[abcs] there could/should be a bool-entry under each cpu-node — for some Zv* entries a subnode might be needed with further parameters). The string-based approach (as in the originally proposed "mmu-type=") would like not scale with the proliferation of small & modular extensions. Philipp. On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com> wrote: > > On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote: > > > > Hi, > > > > Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke: > >> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote: > >>> > >>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner: > >>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt: > >>>>> On 11/29/21 02:40, wefu@redhat.com wrote: > >>>>>> From: Wei Fu <wefu@redhat.com> > >>>>>> > >>>>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt" > >>>>>> in the DT mmu node. Update dt-bindings related property here. > >>>>>> > >>>>>> Signed-off-by: Wei Fu <wefu@redhat.com> > >>>>>> Co-developed-by: Guo Ren <guoren@kernel.org> > >>>>>> Signed-off-by: Guo Ren <guoren@kernel.org> > >>>>>> Cc: Anup Patel <anup@brainfault.org> > >>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com> > >>>>>> Cc: Rob Herring <robh+dt@kernel.org> > >>>>>> --- > >>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++ > >>>>>> 1 file changed, 10 insertions(+) > >>>>>> > >>>>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml > >>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644 > >>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml > >>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml > >>>>>> @@ -63,6 +63,16 @@ properties: > >>>>>> - riscv,sv48 > >>>>>> - riscv,none > >>>>>> > >>>>>> + mmu: > >>>>> > >>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before > >>>>> mmu-type? > >>>>> > >>>>>> + description: > >>>>>> + Describes the CPU's MMU Standard Extensions support. > >>>>>> + These values originate from the RISC-V Privileged > >>>>>> + Specification document, available from > >>>>>> + https://riscv.org/specifications/ > >>>>>> + $ref: '/schemas/types.yaml#/definitions/string' > >>>>>> + enum: > >>>>>> + - riscv,svpmbt > >>>>> > >>>>> The privileged specification has multiple MMU related extensions: > >>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum? > >>>> > >>>> I remember in some earlier version some way back there was the > >>>> suggestion of using a sub-node instead and then adding boolean > >>>> properties for the supported extensions. > >>>> > >>>> Aka something like > >>>> mmu { > >>>> riscv,svpbmt; > >>>> }; > >>> > >>> For the record, I'm talking about the mail from september > >>> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/ > >>> > >>> So having a sub-node would make adding future extensions > >>> way nicer. > >> > >> Svpbmt is just an ISA extension, and should be treated like any other. > >> Let’s not invent two different ways of representing that in the device > >> tree. > > > > Heinrich asked how the other extensions should be handled > > (Svnapot, Svpbmt, Svinval), so what do you suggest to do with these? > > Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may not be > a concrete plan for that yet, but that means you should speak with the > people involved with such extensions and come up with something > appropriate together. > > Jess > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt 2021-11-30 15:01 ` Philipp Tomsich @ 2021-11-30 16:12 ` Jessica Clarke 2021-12-01 1:21 ` Atish Patra 0 siblings, 1 reply; 35+ messages in thread From: Jessica Clarke @ 2021-11-30 16:12 UTC (permalink / raw) To: Philipp Tomsich Cc: Heiko Stübner, linux-riscv, Wei Fu, linux-kernel@vger.kernel.org List, taiten.peng, aniket.ponkshe, gordan.markus, Guo Ren, arnd, wens, maxime, Dan Lustig, Greg Favor, andrea.mondelli, behrensj, xinhaoqu, huffman, Nick Kossifidis, Allen Baum, jscheid, rtrauben, Anup Patel, Rob Herring, Anup Patel, atishp04, Palmer Dabbelt, Guo Ren, Christoph Müllner, hch, liush, Wei Wu, drew, Heinrich Schuchardt On 30 Nov 2021, at 15:01, Philipp Tomsich <philipp.tomsich@vrull.eu> wrote: > > We did touch on this in our coordination call a few weeks ago: the > grouping under mmu and the bool-entries were chosen because of their > similarity to other extensions (i.e. for Zb[abcs] there could/should > be a bool-entry under each cpu-node — for some Zv* entries a subnode > might be needed with further parameters). > > The string-based approach (as in the originally proposed "mmu-type=") > would like not scale with the proliferation of small & modular > extensions. I don’t see why the Sv* extensions need to be under an mmu node then, unless the intent is that every extension be grouped under a sub-node (which doesn’t seem viable due to extensions like Zbk*, unless you group by Ss, Sv and Z)? Also, what is going to happen to the current riscv,isa? Will that continue to exist and duplicate the info, or will kernels be required to reconstruct the string themselves if they want to display it to users? As a FreeBSD developer I’m obviously not a part of many of these discussions, but what the Linux community imposes as the device tree bindings has a real impact on us. Jess > On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com> wrote: >> >> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote: >>> >>> Hi, >>> >>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke: >>>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote: >>>>> >>>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner: >>>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt: >>>>>>> On 11/29/21 02:40, wefu@redhat.com wrote: >>>>>>>> From: Wei Fu <wefu@redhat.com> >>>>>>>> >>>>>>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt" >>>>>>>> in the DT mmu node. Update dt-bindings related property here. >>>>>>>> >>>>>>>> Signed-off-by: Wei Fu <wefu@redhat.com> >>>>>>>> Co-developed-by: Guo Ren <guoren@kernel.org> >>>>>>>> Signed-off-by: Guo Ren <guoren@kernel.org> >>>>>>>> Cc: Anup Patel <anup@brainfault.org> >>>>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com> >>>>>>>> Cc: Rob Herring <robh+dt@kernel.org> >>>>>>>> --- >>>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++ >>>>>>>> 1 file changed, 10 insertions(+) >>>>>>>> >>>>>>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml >>>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644 >>>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml >>>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml >>>>>>>> @@ -63,6 +63,16 @@ properties: >>>>>>>> - riscv,sv48 >>>>>>>> - riscv,none >>>>>>>> >>>>>>>> + mmu: >>>>>>> >>>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before >>>>>>> mmu-type? >>>>>>> >>>>>>>> + description: >>>>>>>> + Describes the CPU's MMU Standard Extensions support. >>>>>>>> + These values originate from the RISC-V Privileged >>>>>>>> + Specification document, available from >>>>>>>> + https://riscv.org/specifications/ >>>>>>>> + $ref: '/schemas/types.yaml#/definitions/string' >>>>>>>> + enum: >>>>>>>> + - riscv,svpmbt >>>>>>> >>>>>>> The privileged specification has multiple MMU related extensions: >>>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum? >>>>>> >>>>>> I remember in some earlier version some way back there was the >>>>>> suggestion of using a sub-node instead and then adding boolean >>>>>> properties for the supported extensions. >>>>>> >>>>>> Aka something like >>>>>> mmu { >>>>>> riscv,svpbmt; >>>>>> }; >>>>> >>>>> For the record, I'm talking about the mail from september >>>>> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/ >>>>> >>>>> So having a sub-node would make adding future extensions >>>>> way nicer. >>>> >>>> Svpbmt is just an ISA extension, and should be treated like any other. >>>> Let’s not invent two different ways of representing that in the device >>>> tree. >>> >>> Heinrich asked how the other extensions should be handled >>> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with these? >> >> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may not be >> a concrete plan for that yet, but that means you should speak with the >> people involved with such extensions and come up with something >> appropriate together. >> >> Jess >> ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt 2021-11-30 16:12 ` Jessica Clarke @ 2021-12-01 1:21 ` Atish Patra 2021-12-01 3:06 ` Tsukasa OI 2021-12-01 13:28 ` Heiko Stübner 0 siblings, 2 replies; 35+ messages in thread From: Atish Patra @ 2021-12-01 1:21 UTC (permalink / raw) To: Jessica Clarke Cc: Philipp Tomsich, Heiko Stübner, linux-riscv, Wei Fu, linux-kernel@vger.kernel.org List, taiten.peng, Aniket Ponkshe, Gordan Markus, Guo Ren, Arnd Bergmann, Chen-Yu Tsai, Maxime Ripard, Dan Lustig, Greg Favor, Andrea Mondelli, Jonathan Behrens, Xinhaoqu, Bill Huffman, Nick Kossifidis, Allen Baum, Josh Scheid, Richard Trauben, Anup Patel, Rob Herring, Anup Patel, atishp04, Palmer Dabbelt, Guo Ren, Christoph Müllner, Christoph Hellwig, liush, Wei Wu, Drew Fustini, Heinrich Schuchardt On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <jrtc27@jrtc27.com> wrote: > > On 30 Nov 2021, at 15:01, Philipp Tomsich <philipp.tomsich@vrull.eu> wrote: > > > > We did touch on this in our coordination call a few weeks ago: the > > grouping under mmu and the bool-entries were chosen because of their > > similarity to other extensions (i.e. for Zb[abcs] there could/should > > be a bool-entry under each cpu-node — for some Zv* entries a subnode > > might be needed with further parameters). > > > > The string-based approach (as in the originally proposed "mmu-type=") > > would like not scale with the proliferation of small & modular > > extensions. > > I don’t see why the Sv* extensions need to be under an mmu node then, > unless the intent is that every extension be grouped under a sub-node > (which doesn’t seem viable due to extensions like Zbk*, unless you > group by Ss, Sv and Z)? > It shouldn't be. All the ISA extensions (i.e. standard, supervisor & hypervisor) with prefix S,Z,H should be kept separate in a separate node for easy parsing. "riscv,isa" dt property will not scale at all. Just look at the few extensions that were ratified this year and Linux kernel needs to support them. "Sscofpmf", "Svpbmt", "Zicbom" > Also, what is going to happen to the current riscv,isa? Will that > continue to exist and duplicate the info, or will kernels be required > to reconstruct the string themselves if they want to display it to > users? > This is my personal preference: riscv,isa will continue to base Standard ISA extensions that have single letter extensions. This new DT node will encode all the non-single letter extensions. I am not sure if it should include some provisions for custom extensions starting with X because that will be platform specific. Again, this is just my personal preference. I will try to send a patch soon so that we can initiate a broader discussion of the scheme and agree/disagree on something. > As a FreeBSD developer I’m obviously not a part of many of these > discussions, but what the Linux community imposes as the device tree > bindings has a real impact on us. > > Jess > > > On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com> wrote: > >> > >> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote: > >>> > >>> Hi, > >>> > >>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke: > >>>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote: > >>>>> > >>>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner: > >>>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt: > >>>>>>> On 11/29/21 02:40, wefu@redhat.com wrote: > >>>>>>>> From: Wei Fu <wefu@redhat.com> > >>>>>>>> > >>>>>>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt" > >>>>>>>> in the DT mmu node. Update dt-bindings related property here. > >>>>>>>> > >>>>>>>> Signed-off-by: Wei Fu <wefu@redhat.com> > >>>>>>>> Co-developed-by: Guo Ren <guoren@kernel.org> > >>>>>>>> Signed-off-by: Guo Ren <guoren@kernel.org> > >>>>>>>> Cc: Anup Patel <anup@brainfault.org> > >>>>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com> > >>>>>>>> Cc: Rob Herring <robh+dt@kernel.org> > >>>>>>>> --- > >>>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++ > >>>>>>>> 1 file changed, 10 insertions(+) > >>>>>>>> > >>>>>>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml > >>>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644 > >>>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml > >>>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml > >>>>>>>> @@ -63,6 +63,16 @@ properties: > >>>>>>>> - riscv,sv48 > >>>>>>>> - riscv,none > >>>>>>>> > >>>>>>>> + mmu: > >>>>>>> > >>>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before > >>>>>>> mmu-type? > >>>>>>> > >>>>>>>> + description: > >>>>>>>> + Describes the CPU's MMU Standard Extensions support. > >>>>>>>> + These values originate from the RISC-V Privileged > >>>>>>>> + Specification document, available from > >>>>>>>> + https://riscv.org/specifications/ > >>>>>>>> + $ref: '/schemas/types.yaml#/definitions/string' > >>>>>>>> + enum: > >>>>>>>> + - riscv,svpmbt > >>>>>>> > >>>>>>> The privileged specification has multiple MMU related extensions: > >>>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum? > >>>>>> > >>>>>> I remember in some earlier version some way back there was the > >>>>>> suggestion of using a sub-node instead and then adding boolean > >>>>>> properties for the supported extensions. > >>>>>> > >>>>>> Aka something like > >>>>>> mmu { > >>>>>> riscv,svpbmt; > >>>>>> }; > >>>>> > >>>>> For the record, I'm talking about the mail from september > >>>>> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/ > >>>>> > >>>>> So having a sub-node would make adding future extensions > >>>>> way nicer. > >>>> > >>>> Svpbmt is just an ISA extension, and should be treated like any other. > >>>> Let’s not invent two different ways of representing that in the device > >>>> tree. > >>> > >>> Heinrich asked how the other extensions should be handled > >>> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with these? > >> > >> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may not be > >> a concrete plan for that yet, but that means you should speak with the > >> people involved with such extensions and come up with something > >> appropriate together. > >> > >> Jess > >> > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv -- Regards, Atish ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt 2021-12-01 1:21 ` Atish Patra @ 2021-12-01 3:06 ` Tsukasa OI 2021-12-01 8:15 ` Atish Patra 2021-12-01 13:28 ` Heiko Stübner 1 sibling, 1 reply; 35+ messages in thread From: Tsukasa OI @ 2021-12-01 3:06 UTC (permalink / raw) To: Atish Patra, Jessica Clarke Cc: Philipp Tomsich, Heiko Stübner, linux-riscv, Wei Fu, linux-kernel@vger.kernel.org List, taiten.peng, Aniket Ponkshe, Gordan Markus, Guo Ren, Arnd Bergmann, Chen-Yu Tsai, Maxime Ripard, Dan Lustig, Greg Favor, Andrea Mondelli, Jonathan Behrens, Xinhaoqu, Bill Huffman, Nick Kossifidis, Allen Baum, Josh Scheid, Richard Trauben, Anup Patel, Rob Herring, Anup Patel, atishp04, Palmer Dabbelt, Guo Ren, Christoph Müllner, Christoph Hellwig, liush, Wei Wu, Drew Fustini, Heinrich Schuchardt On 2021/12/01 10:21, Atish Patra wrote: > On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <jrtc27@jrtc27.com> wrote: >> >> On 30 Nov 2021, at 15:01, Philipp Tomsich <philipp.tomsich@vrull.eu> wrote: >>> >>> We did touch on this in our coordination call a few weeks ago: the >>> grouping under mmu and the bool-entries were chosen because of their >>> similarity to other extensions (i.e. for Zb[abcs] there could/should >>> be a bool-entry under each cpu-node — for some Zv* entries a subnode >>> might be needed with further parameters). >>> >>> The string-based approach (as in the originally proposed "mmu-type=") >>> would like not scale with the proliferation of small & modular >>> extensions. >> >> I don’t see why the Sv* extensions need to be under an mmu node then, >> unless the intent is that every extension be grouped under a sub-node >> (which doesn’t seem viable due to extensions like Zbk*, unless you >> group by Ss, Sv and Z)? >> > > It shouldn't be. All the ISA extensions (i.e. standard, supervisor & hypervisor) > with prefix S,Z,H should be kept separate in a separate node for easy > parsing. "Easy parsing" is not quite convincing. There's a reason other than that I made RFC PATCH to parse multi-letter extensions: v1: <http://lists.infradead.org/pipermail/linux-riscv/2021-November/010252.html> v2: <http://lists.infradead.org/pipermail/linux-riscv/2021-November/010350.html> (note: those patches will break RISC-V KVM because of possible ISA Manual inconsistency and discussion/resolution needed) (...continued below...) > > "riscv,isa" dt property will not scale at all. Just look at the few > extensions that were ratified this year > and Linux kernel needs to support them. > > "Sscofpmf", "Svpbmt", "Zicbom" > >> Also, what is going to happen to the current riscv,isa? Will that >> continue to exist and duplicate the info, or will kernels be required >> to reconstruct the string themselves if they want to display it to >> users? >> > > This is my personal preference: > riscv,isa will continue to base Standard ISA extensions that have > single letter extensions. > > This new DT node will encode all the non-single letter extensions. > I am not sure if it should include some provisions for custom > extensions starting with X because > that will be platform specific. > > Again, this is just my personal preference. I will try to send a patch > soon so that we can initiate a broader > discussion of the scheme and agree/disagree on something. For supervisor-only extensions like "Svpbmt", new DT node would be a reasonable solution (and I would not directly object about that node). However, there's many multi-letter extensions that are useful for user mode. Because "riscv,isa" is exposed via sysfs and procfs (/proc/cpuinfo), it can be really helpful to have multi-letter extensions. Also, current version of Spike, a RISC-V ISA Simulator puts all multi-letter extensions in "riscv,isa" and I thought this is intended. My preference: (1) Allow having multi-letter extensions and versions in "riscv,isa" (2) Adding new DT node for supervisor-related extensions would be reasonable (but I don't strongly agree/disagree). Thanks, Tsukasa > > > >> As a FreeBSD developer I’m obviously not a part of many of these >> discussions, but what the Linux community imposes as the device tree >> bindings has a real impact on us. >> >> Jess >> >>> On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com> wrote: >>>> >>>> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke: >>>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote: >>>>>>> >>>>>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner: >>>>>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt: >>>>>>>>> On 11/29/21 02:40, wefu@redhat.com wrote: >>>>>>>>>> From: Wei Fu <wefu@redhat.com> >>>>>>>>>> >>>>>>>>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt" >>>>>>>>>> in the DT mmu node. Update dt-bindings related property here. >>>>>>>>>> >>>>>>>>>> Signed-off-by: Wei Fu <wefu@redhat.com> >>>>>>>>>> Co-developed-by: Guo Ren <guoren@kernel.org> >>>>>>>>>> Signed-off-by: Guo Ren <guoren@kernel.org> >>>>>>>>>> Cc: Anup Patel <anup@brainfault.org> >>>>>>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com> >>>>>>>>>> Cc: Rob Herring <robh+dt@kernel.org> >>>>>>>>>> --- >>>>>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++ >>>>>>>>>> 1 file changed, 10 insertions(+) >>>>>>>>>> >>>>>>>>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml >>>>>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644 >>>>>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml >>>>>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml >>>>>>>>>> @@ -63,6 +63,16 @@ properties: >>>>>>>>>> - riscv,sv48 >>>>>>>>>> - riscv,none >>>>>>>>>> >>>>>>>>>> + mmu: >>>>>>>>> >>>>>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before >>>>>>>>> mmu-type? >>>>>>>>> >>>>>>>>>> + description: >>>>>>>>>> + Describes the CPU's MMU Standard Extensions support. >>>>>>>>>> + These values originate from the RISC-V Privileged >>>>>>>>>> + Specification document, available from >>>>>>>>>> + https://riscv.org/specifications/ >>>>>>>>>> + $ref: '/schemas/types.yaml#/definitions/string' >>>>>>>>>> + enum: >>>>>>>>>> + - riscv,svpmbt >>>>>>>>> >>>>>>>>> The privileged specification has multiple MMU related extensions: >>>>>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum? >>>>>>>> >>>>>>>> I remember in some earlier version some way back there was the >>>>>>>> suggestion of using a sub-node instead and then adding boolean >>>>>>>> properties for the supported extensions. >>>>>>>> >>>>>>>> Aka something like >>>>>>>> mmu { >>>>>>>> riscv,svpbmt; >>>>>>>> }; >>>>>>> >>>>>>> For the record, I'm talking about the mail from september >>>>>>> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/ >>>>>>> >>>>>>> So having a sub-node would make adding future extensions >>>>>>> way nicer. >>>>>> >>>>>> Svpbmt is just an ISA extension, and should be treated like any other. >>>>>> Let’s not invent two different ways of representing that in the device >>>>>> tree. >>>>> >>>>> Heinrich asked how the other extensions should be handled >>>>> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with these? >>>> >>>> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may not be >>>> a concrete plan for that yet, but that means you should speak with the >>>> people involved with such extensions and come up with something >>>> appropriate together. >>>> >>>> Jess >>>> >> >> >> _______________________________________________ >> linux-riscv mailing list >> linux-riscv@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-riscv > > > > -- > Regards, > Atish > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt 2021-12-01 3:06 ` Tsukasa OI @ 2021-12-01 8:15 ` Atish Patra 2021-12-01 8:30 ` Heiko Stübner 2021-12-02 1:31 ` Tsukasa OI 0 siblings, 2 replies; 35+ messages in thread From: Atish Patra @ 2021-12-01 8:15 UTC (permalink / raw) To: Tsukasa OI Cc: Jessica Clarke, Philipp Tomsich, Heiko Stübner, linux-riscv, Wei Fu, linux-kernel@vger.kernel.org List, taiten.peng, Aniket Ponkshe, Gordan Markus, Guo Ren, Arnd Bergmann, Chen-Yu Tsai, Maxime Ripard, Dan Lustig, Greg Favor, Andrea Mondelli, Jonathan Behrens, Xinhaoqu, Bill Huffman, Nick Kossifidis, Allen Baum, Josh Scheid, Richard Trauben, Anup Patel, Rob Herring, Anup Patel, atishp04, Palmer Dabbelt, Guo Ren, Christoph Müllner, Christoph Hellwig, liush, Wei Wu, Drew Fustini, Heinrich Schuchardt On Tue, Nov 30, 2021 at 7:06 PM Tsukasa OI <research_trasio@irq.a4lg.com> wrote: > > On 2021/12/01 10:21, Atish Patra wrote: > > On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <jrtc27@jrtc27.com> wrote: > >> > >> On 30 Nov 2021, at 15:01, Philipp Tomsich <philipp.tomsich@vrull.eu> wrote: > >>> > >>> We did touch on this in our coordination call a few weeks ago: the > >>> grouping under mmu and the bool-entries were chosen because of their > >>> similarity to other extensions (i.e. for Zb[abcs] there could/should > >>> be a bool-entry under each cpu-node — for some Zv* entries a subnode > >>> might be needed with further parameters). > >>> > >>> The string-based approach (as in the originally proposed "mmu-type=") > >>> would like not scale with the proliferation of small & modular > >>> extensions. > >> > >> I don’t see why the Sv* extensions need to be under an mmu node then, > >> unless the intent is that every extension be grouped under a sub-node > >> (which doesn’t seem viable due to extensions like Zbk*, unless you > >> group by Ss, Sv and Z)? > >> > > > > It shouldn't be. All the ISA extensions (i.e. standard, supervisor & hypervisor) > > with prefix S,Z,H should be kept separate in a separate node for easy > > parsing. > > "Easy parsing" is not quite convincing. The device tree need to carry a very long "riscv,isa" string. The parser need to parse that string in memory as well. > > There's a reason other than that I made RFC PATCH to parse > multi-letter extensions: > > v1: <http://lists.infradead.org/pipermail/linux-riscv/2021-November/010252.html> > v2: <http://lists.infradead.org/pipermail/linux-riscv/2021-November/010350.html> > It's on my todo list to review the series. I think we can work together to propose a better framework for riscv isa extensions. > (note: those patches will break RISC-V KVM because of possible ISA > Manual inconsistency and discussion/resolution needed) > > (...continued below...) > > > > > "riscv,isa" dt property will not scale at all. Just look at the few > > extensions that were ratified this year > > and Linux kernel needs to support them. > > > > "Sscofpmf", "Svpbmt", "Zicbom" > > > >> Also, what is going to happen to the current riscv,isa? Will that > >> continue to exist and duplicate the info, or will kernels be required > >> to reconstruct the string themselves if they want to display it to > >> users? > >> Sorry. I missed this question earlier. See my answer below. > > > > This is my personal preference: > > riscv,isa will continue to base Standard ISA extensions that have > > single letter extensions. > > > > This new DT node will encode all the non-single letter extensions. > > I am not sure if it should include some provisions for custom > > extensions starting with X because > > that will be platform specific. > > > > Again, this is just my personal preference. I will try to send a patch > > soon so that we can initiate a broader > > discussion of the scheme and agree/disagree on something. > > For supervisor-only extensions like "Svpbmt", new DT node would be a > reasonable solution (and I would not directly object about that node). > > However, there's many multi-letter extensions that are useful for > user mode. Because "riscv,isa" is exposed via sysfs and procfs > (/proc/cpuinfo), it can be really helpful to have multi-letter Irrespective of the method chosen to parse the device tree in kernel, we need to provide the extension information to the userspace. This is what I have in mind. An individual row with comma separated extension names for each type of extensions (Ss, Sv, Sh) after the base extension (rv64imafdc) in /proc/cpuinfo output. I am open to other ideas as well. isa rv64imafdc isa-ext-Sv Svpbmt isa-ext-Ss Sscofpmf isa-ext-Sh <hypervisor related extensions> isa-ext-Z Zicbom We can even explicitly name the extensions after isa-ext. However, it may be necessary and too long. I guess you prefer to directly print the entire "riscv,isa" string in "isa" row in /proc/cpuinfo output. It is probably okay with the current number of extensions available today. However, it will become so long string in the future that it has to be broken into multiple lines. > extensions. Also, current version of Spike, a RISC-V ISA Simulator > puts all multi-letter extensions in "riscv,isa" and I thought this is > intended. > > My preference: > (1) Allow having multi-letter extensions and versions in "riscv,isa" > (2) Adding new DT node for supervisor-related extensions would be > reasonable (but I don't strongly agree/disagree). > > Thanks, > Tsukasa > > > > > > > > >> As a FreeBSD developer I’m obviously not a part of many of these > >> discussions, but what the Linux community imposes as the device tree > >> bindings has a real impact on us. > >> > >> Jess > >> > >>> On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com> wrote: > >>>> > >>>> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke: > >>>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote: > >>>>>>> > >>>>>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner: > >>>>>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt: > >>>>>>>>> On 11/29/21 02:40, wefu@redhat.com wrote: > >>>>>>>>>> From: Wei Fu <wefu@redhat.com> > >>>>>>>>>> > >>>>>>>>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt" > >>>>>>>>>> in the DT mmu node. Update dt-bindings related property here. > >>>>>>>>>> > >>>>>>>>>> Signed-off-by: Wei Fu <wefu@redhat.com> > >>>>>>>>>> Co-developed-by: Guo Ren <guoren@kernel.org> > >>>>>>>>>> Signed-off-by: Guo Ren <guoren@kernel.org> > >>>>>>>>>> Cc: Anup Patel <anup@brainfault.org> > >>>>>>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com> > >>>>>>>>>> Cc: Rob Herring <robh+dt@kernel.org> > >>>>>>>>>> --- > >>>>>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++ > >>>>>>>>>> 1 file changed, 10 insertions(+) > >>>>>>>>>> > >>>>>>>>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml > >>>>>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644 > >>>>>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml > >>>>>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml > >>>>>>>>>> @@ -63,6 +63,16 @@ properties: > >>>>>>>>>> - riscv,sv48 > >>>>>>>>>> - riscv,none > >>>>>>>>>> > >>>>>>>>>> + mmu: > >>>>>>>>> > >>>>>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before > >>>>>>>>> mmu-type? > >>>>>>>>> > >>>>>>>>>> + description: > >>>>>>>>>> + Describes the CPU's MMU Standard Extensions support. > >>>>>>>>>> + These values originate from the RISC-V Privileged > >>>>>>>>>> + Specification document, available from > >>>>>>>>>> + https://riscv.org/specifications/ > >>>>>>>>>> + $ref: '/schemas/types.yaml#/definitions/string' > >>>>>>>>>> + enum: > >>>>>>>>>> + - riscv,svpmbt > >>>>>>>>> > >>>>>>>>> The privileged specification has multiple MMU related extensions: > >>>>>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum? > >>>>>>>> > >>>>>>>> I remember in some earlier version some way back there was the > >>>>>>>> suggestion of using a sub-node instead and then adding boolean > >>>>>>>> properties for the supported extensions. > >>>>>>>> > >>>>>>>> Aka something like > >>>>>>>> mmu { > >>>>>>>> riscv,svpbmt; > >>>>>>>> }; > >>>>>>> > >>>>>>> For the record, I'm talking about the mail from september > >>>>>>> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/ > >>>>>>> > >>>>>>> So having a sub-node would make adding future extensions > >>>>>>> way nicer. > >>>>>> > >>>>>> Svpbmt is just an ISA extension, and should be treated like any other. > >>>>>> Let’s not invent two different ways of representing that in the device > >>>>>> tree. > >>>>> > >>>>> Heinrich asked how the other extensions should be handled > >>>>> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with these? > >>>> > >>>> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may not be > >>>> a concrete plan for that yet, but that means you should speak with the > >>>> people involved with such extensions and come up with something > >>>> appropriate together. > >>>> > >>>> Jess > >>>> > >> > >> > >> _______________________________________________ > >> linux-riscv mailing list > >> linux-riscv@lists.infradead.org > >> http://lists.infradead.org/mailman/listinfo/linux-riscv > > > > > > > > -- > > Regards, > > Atish > > > > _______________________________________________ > > linux-riscv mailing list > > linux-riscv@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-riscv > > -- Regards, Atish ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt 2021-12-01 8:15 ` Atish Patra @ 2021-12-01 8:30 ` Heiko Stübner [not found] ` <CAELrHRDb9oeu_FokyhUFQ+Yu27=4xqvPdz4=08MXQzh3Bj2Myw@mail.gmail.com> 2021-12-02 1:31 ` Tsukasa OI 1 sibling, 1 reply; 35+ messages in thread From: Heiko Stübner @ 2021-12-01 8:30 UTC (permalink / raw) To: Tsukasa OI, Atish Patra Cc: Jessica Clarke, Philipp Tomsich, linux-riscv, Wei Fu, linux-kernel@vger.kernel.org List, taiten.peng, Aniket Ponkshe, Gordan Markus, Guo Ren, Arnd Bergmann, Chen-Yu Tsai, Maxime Ripard, Dan Lustig, Greg Favor, Andrea Mondelli, Jonathan Behrens, Xinhaoqu, Bill Huffman, Nick Kossifidis, Allen Baum, Josh Scheid, Richard Trauben, Anup Patel, Rob Herring, Anup Patel, atishp04, Palmer Dabbelt, Guo Ren, Christoph Müllner, Christoph Hellwig, liush, Wei Wu, Drew Fustini, Heinrich Schuchardt Am Mittwoch, 1. Dezember 2021, 09:15:18 CET schrieb Atish Patra: > On Tue, Nov 30, 2021 at 7:06 PM Tsukasa OI <research_trasio@irq.a4lg.com> wrote: > > > > On 2021/12/01 10:21, Atish Patra wrote: > > > On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <jrtc27@jrtc27.com> wrote: > > >> > > >> On 30 Nov 2021, at 15:01, Philipp Tomsich <philipp.tomsich@vrull.eu> wrote: > > >>> > > >>> We did touch on this in our coordination call a few weeks ago: the > > >>> grouping under mmu and the bool-entries were chosen because of their > > >>> similarity to other extensions (i.e. for Zb[abcs] there could/should > > >>> be a bool-entry under each cpu-node — for some Zv* entries a subnode > > >>> might be needed with further parameters). > > >>> > > >>> The string-based approach (as in the originally proposed "mmu-type=") > > >>> would like not scale with the proliferation of small & modular > > >>> extensions. > > >> > > >> I don’t see why the Sv* extensions need to be under an mmu node then, > > >> unless the intent is that every extension be grouped under a sub-node > > >> (which doesn’t seem viable due to extensions like Zbk*, unless you > > >> group by Ss, Sv and Z)? > > >> > > > > > > It shouldn't be. All the ISA extensions (i.e. standard, supervisor & hypervisor) > > > with prefix S,Z,H should be kept separate in a separate node for easy > > > parsing. > > > > "Easy parsing" is not quite convincing. > > The device tree need to carry a very long "riscv,isa" string. The > parser need to parse > that string in memory as well. > > > > > There's a reason other than that I made RFC PATCH to parse > > multi-letter extensions: > > > > v1: <http://lists.infradead.org/pipermail/linux-riscv/2021-November/010252.html> > > v2: <http://lists.infradead.org/pipermail/linux-riscv/2021-November/010350.html> > > > > It's on my todo list to review the series. I think we can work > together to propose a better framework for riscv isa extensions. > > > (note: those patches will break RISC-V KVM because of possible ISA > > Manual inconsistency and discussion/resolution needed) > > > > (...continued below...) > > > > > > > > "riscv,isa" dt property will not scale at all. Just look at the few > > > extensions that were ratified this year > > > and Linux kernel needs to support them. > > > > > > "Sscofpmf", "Svpbmt", "Zicbom" > > > > > >> Also, what is going to happen to the current riscv,isa? Will that > > >> continue to exist and duplicate the info, or will kernels be required > > >> to reconstruct the string themselves if they want to display it to > > >> users? > > >> > > Sorry. I missed this question earlier. See my answer below. > > > > > > > This is my personal preference: > > > riscv,isa will continue to base Standard ISA extensions that have > > > single letter extensions. > > > > > > This new DT node will encode all the non-single letter extensions. > > > I am not sure if it should include some provisions for custom > > > extensions starting with X because > > > that will be platform specific. > > > > > > Again, this is just my personal preference. I will try to send a patch > > > soon so that we can initiate a broader > > > discussion of the scheme and agree/disagree on something. > > > > For supervisor-only extensions like "Svpbmt", new DT node would be a > > reasonable solution (and I would not directly object about that node). > > > > However, there's many multi-letter extensions that are useful for > > user mode. Because "riscv,isa" is exposed via sysfs and procfs > > (/proc/cpuinfo), it can be really helpful to have multi-letter > > Irrespective of the method chosen to parse the device tree in kernel, > we need to provide the extension information to the userspace. > > This is what I have in mind. An individual row with comma separated > extension names for each type of extensions (Ss, Sv, Sh) > after the base extension (rv64imafdc) in /proc/cpuinfo output. I am > open to other ideas as well. > > isa rv64imafdc > isa-ext-Sv Svpbmt > isa-ext-Ss Sscofpmf > isa-ext-Sh <hypervisor related extensions> > isa-ext-Z Zicbom > > We can even explicitly name the extensions after isa-ext. However, it > may be necessary and too long. Aren't other architectures just using a flags [x86] or features [arm64] line in cpuinfo to expose the available additional cpu features as a space-separated list? So you could also just do something similar like isa: rv64imafdc isa-ext: Svpbmt Sscofpmf foo bar That would make a nice compromise between length and readability by users I guess? Heiko > I guess you prefer to directly print the entire "riscv,isa" string in > "isa" row in /proc/cpuinfo output. > It is probably okay with the current number of extensions available > today. However, it will become so long string > in the future that it has to be broken into multiple lines. > > > extensions. Also, current version of Spike, a RISC-V ISA Simulator > > puts all multi-letter extensions in "riscv,isa" and I thought this is > > intended. > > > > My preference: > > (1) Allow having multi-letter extensions and versions in "riscv,isa" > > (2) Adding new DT node for supervisor-related extensions would be > > reasonable (but I don't strongly agree/disagree). > > > > Thanks, > > Tsukasa > > > > > > > > > > > > > >> As a FreeBSD developer I’m obviously not a part of many of these > > >> discussions, but what the Linux community imposes as the device tree > > >> bindings has a real impact on us. > > >> > > >> Jess > > >> > > >>> On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com> wrote: > > >>>> > > >>>> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote: > > >>>>> > > >>>>> Hi, > > >>>>> > > >>>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke: > > >>>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote: > > >>>>>>> > > >>>>>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner: > > >>>>>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt: > > >>>>>>>>> On 11/29/21 02:40, wefu@redhat.com wrote: > > >>>>>>>>>> From: Wei Fu <wefu@redhat.com> > > >>>>>>>>>> > > >>>>>>>>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt" > > >>>>>>>>>> in the DT mmu node. Update dt-bindings related property here. > > >>>>>>>>>> > > >>>>>>>>>> Signed-off-by: Wei Fu <wefu@redhat.com> > > >>>>>>>>>> Co-developed-by: Guo Ren <guoren@kernel.org> > > >>>>>>>>>> Signed-off-by: Guo Ren <guoren@kernel.org> > > >>>>>>>>>> Cc: Anup Patel <anup@brainfault.org> > > >>>>>>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com> > > >>>>>>>>>> Cc: Rob Herring <robh+dt@kernel.org> > > >>>>>>>>>> --- > > >>>>>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++ > > >>>>>>>>>> 1 file changed, 10 insertions(+) > > >>>>>>>>>> > > >>>>>>>>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml > > >>>>>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644 > > >>>>>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml > > >>>>>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml > > >>>>>>>>>> @@ -63,6 +63,16 @@ properties: > > >>>>>>>>>> - riscv,sv48 > > >>>>>>>>>> - riscv,none > > >>>>>>>>>> > > >>>>>>>>>> + mmu: > > >>>>>>>>> > > >>>>>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before > > >>>>>>>>> mmu-type? > > >>>>>>>>> > > >>>>>>>>>> + description: > > >>>>>>>>>> + Describes the CPU's MMU Standard Extensions support. > > >>>>>>>>>> + These values originate from the RISC-V Privileged > > >>>>>>>>>> + Specification document, available from > > >>>>>>>>>> + https://riscv.org/specifications/ > > >>>>>>>>>> + $ref: '/schemas/types.yaml#/definitions/string' > > >>>>>>>>>> + enum: > > >>>>>>>>>> + - riscv,svpmbt > > >>>>>>>>> > > >>>>>>>>> The privileged specification has multiple MMU related extensions: > > >>>>>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum? > > >>>>>>>> > > >>>>>>>> I remember in some earlier version some way back there was the > > >>>>>>>> suggestion of using a sub-node instead and then adding boolean > > >>>>>>>> properties for the supported extensions. > > >>>>>>>> > > >>>>>>>> Aka something like > > >>>>>>>> mmu { > > >>>>>>>> riscv,svpbmt; > > >>>>>>>> }; > > >>>>>>> > > >>>>>>> For the record, I'm talking about the mail from september > > >>>>>>> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/ > > >>>>>>> > > >>>>>>> So having a sub-node would make adding future extensions > > >>>>>>> way nicer. > > >>>>>> > > >>>>>> Svpbmt is just an ISA extension, and should be treated like any other. > > >>>>>> Let’s not invent two different ways of representing that in the device > > >>>>>> tree. > > >>>>> > > >>>>> Heinrich asked how the other extensions should be handled > > >>>>> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with these? > > >>>> > > >>>> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may not be > > >>>> a concrete plan for that yet, but that means you should speak with the > > >>>> people involved with such extensions and come up with something > > >>>> appropriate together. > > >>>> > > >>>> Jess > > >>>> > > >> > > >> > > >> _______________________________________________ > > >> linux-riscv mailing list > > >> linux-riscv@lists.infradead.org > > >> http://lists.infradead.org/mailman/listinfo/linux-riscv > > > > > > > > > > > > -- > > > Regards, > > > Atish > > > > > > _______________________________________________ > > > linux-riscv mailing list > > > linux-riscv@lists.infradead.org > > > http://lists.infradead.org/mailman/listinfo/linux-riscv > > > > > > > ^ permalink raw reply [flat|nested] 35+ messages in thread
[parent not found: <CAELrHRDb9oeu_FokyhUFQ+Yu27=4xqvPdz4=08MXQzh3Bj2Myw@mail.gmail.com>]
* Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt [not found] ` <CAELrHRDb9oeu_FokyhUFQ+Yu27=4xqvPdz4=08MXQzh3Bj2Myw@mail.gmail.com> @ 2021-12-01 10:20 ` Heiko Stübner 2021-12-01 11:05 ` Philipp Tomsich 0 siblings, 1 reply; 35+ messages in thread From: Heiko Stübner @ 2021-12-01 10:20 UTC (permalink / raw) To: atish patra Cc: Tsukasa OI, Atish Patra, Jessica Clarke, Philipp Tomsich, linux-riscv, Wei Fu, linux-kernel@vger.kernel.org List, taiten.peng, Aniket Ponkshe, Gordan Markus, Guo Ren, Arnd Bergmann, Chen-Yu Tsai, Maxime Ripard, Dan Lustig, Greg Favor, Andrea Mondelli, Jonathan Behrens, Xinhaoqu, Bill Huffman, Nick Kossifidis, Allen Baum, Josh Scheid, Richard Trauben, Anup Patel, Rob Herring, Anup Patel, Palmer Dabbelt, Guo Ren, Christoph Müllner, Christoph Hellwig, liush, Wei Wu, Drew Fustini, Heinrich Schuchardt Am Mittwoch, 1. Dezember 2021, 09:41:48 CET schrieb atish patra: > On Wed, Dec 1, 2021 at 12:30 AM Heiko Stübner <heiko@sntech.de> wrote: > > > Am Mittwoch, 1. Dezember 2021, 09:15:18 CET schrieb Atish Patra: > > > On Tue, Nov 30, 2021 at 7:06 PM Tsukasa OI <research_trasio@irq.a4lg.com> > > wrote: > > > > > > > > On 2021/12/01 10:21, Atish Patra wrote: > > > > > On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <jrtc27@jrtc27.com> > > wrote: > > > > >> > > > > >> On 30 Nov 2021, at 15:01, Philipp Tomsich <philipp.tomsich@vrull.eu> > > wrote: > > > > >>> > > > > >>> We did touch on this in our coordination call a few weeks ago: the > > > > >>> grouping under mmu and the bool-entries were chosen because of > > their > > > > >>> similarity to other extensions (i.e. for Zb[abcs] there > > could/should > > > > >>> be a bool-entry under each cpu-node — for some Zv* entries a > > subnode > > > > >>> might be needed with further parameters). > > > > >>> > > > > >>> The string-based approach (as in the originally proposed > > "mmu-type=") > > > > >>> would like not scale with the proliferation of small & modular > > > > >>> extensions. > > > > >> > > > > >> I don’t see why the Sv* extensions need to be under an mmu node > > then, > > > > >> unless the intent is that every extension be grouped under a > > sub-node > > > > >> (which doesn’t seem viable due to extensions like Zbk*, unless you > > > > >> group by Ss, Sv and Z)? > > > > >> > > > > > > > > > > It shouldn't be. All the ISA extensions (i.e. standard, supervisor & > > hypervisor) > > > > > with prefix S,Z,H should be kept separate in a separate node for easy > > > > > parsing. > > > > > > > > "Easy parsing" is not quite convincing. > > > > > > The device tree need to carry a very long "riscv,isa" string. The > > > parser need to parse > > > that string in memory as well. > > > > > > > > > > > There's a reason other than that I made RFC PATCH to parse > > > > multi-letter extensions: > > > > > > > > v1: < > > http://lists.infradead.org/pipermail/linux-riscv/2021-November/010252.html > > > > > > > v2: < > > http://lists.infradead.org/pipermail/linux-riscv/2021-November/010350.html > > > > > > > > > > > > > It's on my todo list to review the series. I think we can work > > > together to propose a better framework for riscv isa extensions. > > > > > > > (note: those patches will break RISC-V KVM because of possible ISA > > > > Manual inconsistency and discussion/resolution needed) > > > > > > > > (...continued below...) > > > > > > > > > > > > > > "riscv,isa" dt property will not scale at all. Just look at the few > > > > > extensions that were ratified this year > > > > > and Linux kernel needs to support them. > > > > > > > > > > "Sscofpmf", "Svpbmt", "Zicbom" > > > > > > > > > >> Also, what is going to happen to the current riscv,isa? Will that > > > > >> continue to exist and duplicate the info, or will kernels be > > required > > > > >> to reconstruct the string themselves if they want to display it to > > > > >> users? > > > > >> > > > > > > Sorry. I missed this question earlier. See my answer below. > > > > > > > > > > > > > This is my personal preference: > > > > > riscv,isa will continue to base Standard ISA extensions that have > > > > > single letter extensions. > > > > > > > > > > This new DT node will encode all the non-single letter extensions. > > > > > I am not sure if it should include some provisions for custom > > > > > extensions starting with X because > > > > > that will be platform specific. > > > > > > > > > > Again, this is just my personal preference. I will try to send a > > patch > > > > > soon so that we can initiate a broader > > > > > discussion of the scheme and agree/disagree on something. > > > > > > > > For supervisor-only extensions like "Svpbmt", new DT node would be a > > > > reasonable solution (and I would not directly object about that node). > > > > > > > > However, there's many multi-letter extensions that are useful for > > > > user mode. Because "riscv,isa" is exposed via sysfs and procfs > > > > (/proc/cpuinfo), it can be really helpful to have multi-letter > > > > > > Irrespective of the method chosen to parse the device tree in kernel, > > > we need to provide the extension information to the userspace. > > > > > > This is what I have in mind. An individual row with comma separated > > > extension names for each type of extensions (Ss, Sv, Sh) > > > after the base extension (rv64imafdc) in /proc/cpuinfo output. I am > > > open to other ideas as well. > > > > > > isa rv64imafdc > > > isa-ext-Sv Svpbmt > > > isa-ext-Ss Sscofpmf > > > isa-ext-Sh <hypervisor related extensions> > > > isa-ext-Z Zicbom > > > > > > We can even explicitly name the extensions after isa-ext. However, it > > > may be necessary and too long. > > > > Aren't other architectures just using a flags [x86] or features [arm64] > > line in cpuinfo to expose the available additional cpu features > > as a space-separated list? > > > > So you could also just do something similar like > > isa: rv64imafdc > > isa-ext: Svpbmt Sscofpmf foo bar > > > > > A space separated list is also fine by me. > Should we keep all the extensions as one row or split based on the type of > extensions (Ss, Sv, Sh,)? > > When I look at the flags in x86, my eyes hurt badly ;) On arm64 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid or on arm32 Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm > That's why I suggested splitting by type of extensions to improve > readability. Though I guess with that split you introduce more requirements on userspace? Because things that parse cpuinfo (think some python library) will need to be updated when some new extension category surfaces? > > That would make a nice compromise between length and readability > > by users I guess? > > > > > > Heiko > > > > > I guess you prefer to directly print the entire "riscv,isa" string in > > > "isa" row in /proc/cpuinfo output. > > > It is probably okay with the current number of extensions available > > > today. However, it will become so long string > > > in the future that it has to be broken into multiple lines. > > > > > > > extensions. Also, current version of Spike, a RISC-V ISA Simulator > > > > puts all multi-letter extensions in "riscv,isa" and I thought this is > > > > intended. > > > > > > > > My preference: > > > > (1) Allow having multi-letter extensions and versions in "riscv,isa" > > > > (2) Adding new DT node for supervisor-related extensions would be > > > > reasonable (but I don't strongly agree/disagree). > > > > > > > > Thanks, > > > > Tsukasa > > > > > > > > > > > > > > > > > > > > > > > >> As a FreeBSD developer I’m obviously not a part of many of these > > > > >> discussions, but what the Linux community imposes as the device tree > > > > >> bindings has a real impact on us. > > > > >> > > > > >> Jess > > > > >> > > > > >>> On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com> > > wrote: > > > > >>>> > > > > >>>> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote: > > > > >>>>> > > > > >>>>> Hi, > > > > >>>>> > > > > >>>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica > > Clarke: > > > > >>>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> > > wrote: > > > > >>>>>>> > > > > >>>>>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko > > Stübner: > > > > >>>>>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich > > Schuchardt: > > > > >>>>>>>>> On 11/29/21 02:40, wefu@redhat.com wrote: > > > > >>>>>>>>>> From: Wei Fu <wefu@redhat.com> > > > > >>>>>>>>>> > > > > >>>>>>>>>> Previous patch has added svpbmt in arch/riscv and add > > "riscv,svpmbt" > > > > >>>>>>>>>> in the DT mmu node. Update dt-bindings related property > > here. > > > > >>>>>>>>>> > > > > >>>>>>>>>> Signed-off-by: Wei Fu <wefu@redhat.com> > > > > >>>>>>>>>> Co-developed-by: Guo Ren <guoren@kernel.org> > > > > >>>>>>>>>> Signed-off-by: Guo Ren <guoren@kernel.org> > > > > >>>>>>>>>> Cc: Anup Patel <anup@brainfault.org> > > > > >>>>>>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com> > > > > >>>>>>>>>> Cc: Rob Herring <robh+dt@kernel.org> > > > > >>>>>>>>>> --- > > > > >>>>>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 > > ++++++++++ > > > > >>>>>>>>>> 1 file changed, 10 insertions(+) > > > > >>>>>>>>>> > > > > >>>>>>>>>> diff --git > > a/Documentation/devicetree/bindings/riscv/cpus.yaml > > b/Documentation/devicetree/bindings/riscv/cpus.yaml > > > > >>>>>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644 > > > > >>>>>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml > > > > >>>>>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml > > > > >>>>>>>>>> @@ -63,6 +63,16 @@ properties: > > > > >>>>>>>>>> - riscv,sv48 > > > > >>>>>>>>>> - riscv,none > > > > >>>>>>>>>> > > > > >>>>>>>>>> + mmu: > > > > >>>>>>>>> > > > > >>>>>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu > > before > > > > >>>>>>>>> mmu-type? > > > > >>>>>>>>> > > > > >>>>>>>>>> + description: > > > > >>>>>>>>>> + Describes the CPU's MMU Standard Extensions support. > > > > >>>>>>>>>> + These values originate from the RISC-V Privileged > > > > >>>>>>>>>> + Specification document, available from > > > > >>>>>>>>>> + https://riscv.org/specifications/ > > > > >>>>>>>>>> + $ref: '/schemas/types.yaml#/definitions/string' > > > > >>>>>>>>>> + enum: > > > > >>>>>>>>>> + - riscv,svpmbt > > > > >>>>>>>>> > > > > >>>>>>>>> The privileged specification has multiple MMU related > > extensions: > > > > >>>>>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this > > enum? > > > > >>>>>>>> > > > > >>>>>>>> I remember in some earlier version some way back there was the > > > > >>>>>>>> suggestion of using a sub-node instead and then adding boolean > > > > >>>>>>>> properties for the supported extensions. > > > > >>>>>>>> > > > > >>>>>>>> Aka something like > > > > >>>>>>>> mmu { > > > > >>>>>>>> riscv,svpbmt; > > > > >>>>>>>> }; > > > > >>>>>>> > > > > >>>>>>> For the record, I'm talking about the mail from september > > > > >>>>>>> > > https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/ > > > > >>>>>>> > > > > >>>>>>> So having a sub-node would make adding future extensions > > > > >>>>>>> way nicer. > > > > >>>>>> > > > > >>>>>> Svpbmt is just an ISA extension, and should be treated like any > > other. > > > > >>>>>> Let’s not invent two different ways of representing that in the > > device > > > > >>>>>> tree. > > > > >>>>> > > > > >>>>> Heinrich asked how the other extensions should be handled > > > > >>>>> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with > > these? > > > > >>>> > > > > >>>> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may > > not be > > > > >>>> a concrete plan for that yet, but that means you should speak > > with the > > > > >>>> people involved with such extensions and come up with something > > > > >>>> appropriate together. > > > > >>>> > > > > >>>> Jess > > > > >>>> > > > > >> > > > > >> > > > > >> _______________________________________________ > > > > >> linux-riscv mailing list > > > > >> linux-riscv@lists.infradead.org > > > > >> http://lists.infradead.org/mailman/listinfo/linux-riscv > > > > > > > > > > > > > > > > > > > > -- > > > > > Regards, > > > > > Atish > > > > > > > > > > _______________________________________________ > > > > > linux-riscv mailing list > > > > > linux-riscv@lists.infradead.org > > > > > http://lists.infradead.org/mailman/listinfo/linux-riscv > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt 2021-12-01 10:20 ` Heiko Stübner @ 2021-12-01 11:05 ` Philipp Tomsich 2021-12-01 13:39 ` Jessica Clarke 0 siblings, 1 reply; 35+ messages in thread From: Philipp Tomsich @ 2021-12-01 11:05 UTC (permalink / raw) To: Heiko Stübner Cc: atish patra, Tsukasa OI, Atish Patra, Jessica Clarke, linux-riscv, Wei Fu, linux-kernel@vger.kernel.org List, taiten.peng, Aniket Ponkshe, Gordan Markus, Guo Ren, Arnd Bergmann, Chen-Yu Tsai, Maxime Ripard, Dan Lustig, Greg Favor, Andrea Mondelli, Jonathan Behrens, Xinhaoqu, Bill Huffman, Nick Kossifidis, Allen Baum, Josh Scheid, Richard Trauben, Anup Patel, Rob Herring, Anup Patel, Palmer Dabbelt, Guo Ren, Christoph Müllner, Christoph Hellwig, liush, Wei Wu, Drew Fustini, Heinrich Schuchardt I hope that cpuinfo is for human consumption only, as we will inject this info in machine-readable form via the ELF auxiliary vector. We had briefly discussed this as part of psABI and during Kito's presentation at LPC. If we can agree that this is for human consumption only, then we should aim at making it easy to read for humans (and not care too much about how easy this will be to parse). Philipp. On Wed, 1 Dec 2021 at 11:21, Heiko Stübner <heiko@sntech.de> wrote: > > Am Mittwoch, 1. Dezember 2021, 09:41:48 CET schrieb atish patra: > > On Wed, Dec 1, 2021 at 12:30 AM Heiko Stübner <heiko@sntech.de> wrote: > > > > > Am Mittwoch, 1. Dezember 2021, 09:15:18 CET schrieb Atish Patra: > > > > On Tue, Nov 30, 2021 at 7:06 PM Tsukasa OI <research_trasio@irq.a4lg.com> > > > wrote: > > > > > > > > > > On 2021/12/01 10:21, Atish Patra wrote: > > > > > > On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <jrtc27@jrtc27.com> > > > wrote: > > > > > >> > > > > > >> On 30 Nov 2021, at 15:01, Philipp Tomsich <philipp.tomsich@vrull.eu> > > > wrote: > > > > > >>> > > > > > >>> We did touch on this in our coordination call a few weeks ago: the > > > > > >>> grouping under mmu and the bool-entries were chosen because of > > > their > > > > > >>> similarity to other extensions (i.e. for Zb[abcs] there > > > could/should > > > > > >>> be a bool-entry under each cpu-node — for some Zv* entries a > > > subnode > > > > > >>> might be needed with further parameters). > > > > > >>> > > > > > >>> The string-based approach (as in the originally proposed > > > "mmu-type=") > > > > > >>> would like not scale with the proliferation of small & modular > > > > > >>> extensions. > > > > > >> > > > > > >> I don’t see why the Sv* extensions need to be under an mmu node > > > then, > > > > > >> unless the intent is that every extension be grouped under a > > > sub-node > > > > > >> (which doesn’t seem viable due to extensions like Zbk*, unless you > > > > > >> group by Ss, Sv and Z)? > > > > > >> > > > > > > > > > > > > It shouldn't be. All the ISA extensions (i.e. standard, supervisor & > > > hypervisor) > > > > > > with prefix S,Z,H should be kept separate in a separate node for easy > > > > > > parsing. > > > > > > > > > > "Easy parsing" is not quite convincing. > > > > > > > > The device tree need to carry a very long "riscv,isa" string. The > > > > parser need to parse > > > > that string in memory as well. > > > > > > > > > > > > > > There's a reason other than that I made RFC PATCH to parse > > > > > multi-letter extensions: > > > > > > > > > > v1: < > > > http://lists.infradead.org/pipermail/linux-riscv/2021-November/010252.html > > > > > > > > > v2: < > > > http://lists.infradead.org/pipermail/linux-riscv/2021-November/010350.html > > > > > > > > > > > > > > > > > It's on my todo list to review the series. I think we can work > > > > together to propose a better framework for riscv isa extensions. > > > > > > > > > (note: those patches will break RISC-V KVM because of possible ISA > > > > > Manual inconsistency and discussion/resolution needed) > > > > > > > > > > (...continued below...) > > > > > > > > > > > > > > > > > "riscv,isa" dt property will not scale at all. Just look at the few > > > > > > extensions that were ratified this year > > > > > > and Linux kernel needs to support them. > > > > > > > > > > > > "Sscofpmf", "Svpbmt", "Zicbom" > > > > > > > > > > > >> Also, what is going to happen to the current riscv,isa? Will that > > > > > >> continue to exist and duplicate the info, or will kernels be > > > required > > > > > >> to reconstruct the string themselves if they want to display it to > > > > > >> users? > > > > > >> > > > > > > > > Sorry. I missed this question earlier. See my answer below. > > > > > > > > > > > > > > > > This is my personal preference: > > > > > > riscv,isa will continue to base Standard ISA extensions that have > > > > > > single letter extensions. > > > > > > > > > > > > This new DT node will encode all the non-single letter extensions. > > > > > > I am not sure if it should include some provisions for custom > > > > > > extensions starting with X because > > > > > > that will be platform specific. > > > > > > > > > > > > Again, this is just my personal preference. I will try to send a > > > patch > > > > > > soon so that we can initiate a broader > > > > > > discussion of the scheme and agree/disagree on something. > > > > > > > > > > For supervisor-only extensions like "Svpbmt", new DT node would be a > > > > > reasonable solution (and I would not directly object about that node). > > > > > > > > > > However, there's many multi-letter extensions that are useful for > > > > > user mode. Because "riscv,isa" is exposed via sysfs and procfs > > > > > (/proc/cpuinfo), it can be really helpful to have multi-letter > > > > > > > > Irrespective of the method chosen to parse the device tree in kernel, > > > > we need to provide the extension information to the userspace. > > > > > > > > This is what I have in mind. An individual row with comma separated > > > > extension names for each type of extensions (Ss, Sv, Sh) > > > > after the base extension (rv64imafdc) in /proc/cpuinfo output. I am > > > > open to other ideas as well. > > > > > > > > isa rv64imafdc > > > > isa-ext-Sv Svpbmt > > > > isa-ext-Ss Sscofpmf > > > > isa-ext-Sh <hypervisor related extensions> > > > > isa-ext-Z Zicbom > > > > > > > > We can even explicitly name the extensions after isa-ext. However, it > > > > may be necessary and too long. > > > > > > Aren't other architectures just using a flags [x86] or features [arm64] > > > line in cpuinfo to expose the available additional cpu features > > > as a space-separated list? > > > > > > So you could also just do something similar like > > > isa: rv64imafdc > > > isa-ext: Svpbmt Sscofpmf foo bar > > > > > > > > A space separated list is also fine by me. > > Should we keep all the extensions as one row or split based on the type of > > extensions (Ss, Sv, Sh,)? > > > > When I look at the flags in x86, my eyes hurt badly ;) > > On arm64 > Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid > > or on arm32 > Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm > > > > That's why I suggested splitting by type of extensions to improve > > readability. > > Though I guess with that split you introduce more requirements on userspace? > Because things that parse cpuinfo (think some python library) will need to > be updated when some new extension category surfaces? > > > > > > That would make a nice compromise between length and readability > > > by users I guess? > > > > > > > > > Heiko > > > > > > > I guess you prefer to directly print the entire "riscv,isa" string in > > > > "isa" row in /proc/cpuinfo output. > > > > It is probably okay with the current number of extensions available > > > > today. However, it will become so long string > > > > in the future that it has to be broken into multiple lines. > > > > > > > > > extensions. Also, current version of Spike, a RISC-V ISA Simulator > > > > > puts all multi-letter extensions in "riscv,isa" and I thought this is > > > > > intended. > > > > > > > > > > My preference: > > > > > (1) Allow having multi-letter extensions and versions in "riscv,isa" > > > > > (2) Adding new DT node for supervisor-related extensions would be > > > > > reasonable (but I don't strongly agree/disagree). > > > > > > > > > > Thanks, > > > > > Tsukasa > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> As a FreeBSD developer I’m obviously not a part of many of these > > > > > >> discussions, but what the Linux community imposes as the device tree > > > > > >> bindings has a real impact on us. > > > > > >> > > > > > >> Jess > > > > > >> > > > > > >>> On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com> > > > wrote: > > > > > >>>> > > > > > >>>> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote: > > > > > >>>>> > > > > > >>>>> Hi, > > > > > >>>>> > > > > > >>>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica > > > Clarke: > > > > > >>>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> > > > wrote: > > > > > >>>>>>> > > > > > >>>>>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko > > > Stübner: > > > > > >>>>>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich > > > Schuchardt: > > > > > >>>>>>>>> On 11/29/21 02:40, wefu@redhat.com wrote: > > > > > >>>>>>>>>> From: Wei Fu <wefu@redhat.com> > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> Previous patch has added svpbmt in arch/riscv and add > > > "riscv,svpmbt" > > > > > >>>>>>>>>> in the DT mmu node. Update dt-bindings related property > > > here. > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> Signed-off-by: Wei Fu <wefu@redhat.com> > > > > > >>>>>>>>>> Co-developed-by: Guo Ren <guoren@kernel.org> > > > > > >>>>>>>>>> Signed-off-by: Guo Ren <guoren@kernel.org> > > > > > >>>>>>>>>> Cc: Anup Patel <anup@brainfault.org> > > > > > >>>>>>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com> > > > > > >>>>>>>>>> Cc: Rob Herring <robh+dt@kernel.org> > > > > > >>>>>>>>>> --- > > > > > >>>>>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 > > > ++++++++++ > > > > > >>>>>>>>>> 1 file changed, 10 insertions(+) > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> diff --git > > > a/Documentation/devicetree/bindings/riscv/cpus.yaml > > > b/Documentation/devicetree/bindings/riscv/cpus.yaml > > > > > >>>>>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644 > > > > > >>>>>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml > > > > > >>>>>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml > > > > > >>>>>>>>>> @@ -63,6 +63,16 @@ properties: > > > > > >>>>>>>>>> - riscv,sv48 > > > > > >>>>>>>>>> - riscv,none > > > > > >>>>>>>>>> > > > > > >>>>>>>>>> + mmu: > > > > > >>>>>>>>> > > > > > >>>>>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu > > > before > > > > > >>>>>>>>> mmu-type? > > > > > >>>>>>>>> > > > > > >>>>>>>>>> + description: > > > > > >>>>>>>>>> + Describes the CPU's MMU Standard Extensions support. > > > > > >>>>>>>>>> + These values originate from the RISC-V Privileged > > > > > >>>>>>>>>> + Specification document, available from > > > > > >>>>>>>>>> + https://riscv.org/specifications/ > > > > > >>>>>>>>>> + $ref: '/schemas/types.yaml#/definitions/string' > > > > > >>>>>>>>>> + enum: > > > > > >>>>>>>>>> + - riscv,svpmbt > > > > > >>>>>>>>> > > > > > >>>>>>>>> The privileged specification has multiple MMU related > > > extensions: > > > > > >>>>>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this > > > enum? > > > > > >>>>>>>> > > > > > >>>>>>>> I remember in some earlier version some way back there was the > > > > > >>>>>>>> suggestion of using a sub-node instead and then adding boolean > > > > > >>>>>>>> properties for the supported extensions. > > > > > >>>>>>>> > > > > > >>>>>>>> Aka something like > > > > > >>>>>>>> mmu { > > > > > >>>>>>>> riscv,svpbmt; > > > > > >>>>>>>> }; > > > > > >>>>>>> > > > > > >>>>>>> For the record, I'm talking about the mail from september > > > > > >>>>>>> > > > https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/ > > > > > >>>>>>> > > > > > >>>>>>> So having a sub-node would make adding future extensions > > > > > >>>>>>> way nicer. > > > > > >>>>>> > > > > > >>>>>> Svpbmt is just an ISA extension, and should be treated like any > > > other. > > > > > >>>>>> Let’s not invent two different ways of representing that in the > > > device > > > > > >>>>>> tree. > > > > > >>>>> > > > > > >>>>> Heinrich asked how the other extensions should be handled > > > > > >>>>> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with > > > these? > > > > > >>>> > > > > > >>>> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may > > > not be > > > > > >>>> a concrete plan for that yet, but that means you should speak > > > with the > > > > > >>>> people involved with such extensions and come up with something > > > > > >>>> appropriate together. > > > > > >>>> > > > > > >>>> Jess > > > > > >>>> > > > > > >> > > > > > >> > > > > > >> _______________________________________________ > > > > > >> linux-riscv mailing list > > > > > >> linux-riscv@lists.infradead.org > > > > > >> http://lists.infradead.org/mailman/listinfo/linux-riscv > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Regards, > > > > > > Atish > > > > > > > > > > > > _______________________________________________ > > > > > > linux-riscv mailing list > > > > > > linux-riscv@lists.infradead.org > > > > > > http://lists.infradead.org/mailman/listinfo/linux-riscv > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt 2021-12-01 11:05 ` Philipp Tomsich @ 2021-12-01 13:39 ` Jessica Clarke 0 siblings, 0 replies; 35+ messages in thread From: Jessica Clarke @ 2021-12-01 13:39 UTC (permalink / raw) To: Philipp Tomsich Cc: Heiko Stübner, atish patra, Tsukasa OI, Atish Patra, linux-riscv, Wei Fu, linux-kernel@vger.kernel.org List, taiten.peng, Aniket Ponkshe, Gordan Markus, Guo Ren, Arnd Bergmann, Chen-Yu Tsai, Maxime Ripard, Dan Lustig, Greg Favor, Andrea Mondelli, Jonathan Behrens, Xinhaoqu, Bill Huffman, Nick Kossifidis, Allen Baum, Josh Scheid, Richard Trauben, Anup Patel, Rob Herring, Anup Patel, Palmer Dabbelt, Guo Ren, Christoph Müllner, Christoph Hellwig, liush, Wei Wu, Drew Fustini, Heinrich Schuchardt On 1 Dec 2021, at 11:05, Philipp Tomsich <philipp.tomsich@vrull.eu> wrote: > > I hope that cpuinfo is for human consumption only, as we will inject > this info in machine-readable form via the ELF auxiliary vector. > We had briefly discussed this as part of psABI and during Kito's > presentation at LPC. > > If we can agree that this is for human consumption only, then we > should aim at making it easy to read for humans (and not care too much > about how easy this will be to parse). If it's human-readable then why is it formatted in such a machine-readable way? A lot of software parses it[1]. Including lscpu. There’s lots of information there that won’t appear in AT_HWCAP or similar as it’s not generally relevant to userspace (processor speed, supervisor-level extensions, physical hartid, ...). Jess [1] https://codesearch.debian.net/search?q=%22%2Fproc%2Fcpuinfo%22&literal=1&perpkg=1 > On Wed, 1 Dec 2021 at 11:21, Heiko Stübner <heiko@sntech.de> wrote: >> >> Am Mittwoch, 1. Dezember 2021, 09:41:48 CET schrieb atish patra: >>> On Wed, Dec 1, 2021 at 12:30 AM Heiko Stübner <heiko@sntech.de> wrote: >>> >>>> Am Mittwoch, 1. Dezember 2021, 09:15:18 CET schrieb Atish Patra: >>>>> On Tue, Nov 30, 2021 at 7:06 PM Tsukasa OI <research_trasio@irq.a4lg.com> >>>> wrote: >>>>>> >>>>>> On 2021/12/01 10:21, Atish Patra wrote: >>>>>>> On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <jrtc27@jrtc27.com> >>>> wrote: >>>>>>>> >>>>>>>> On 30 Nov 2021, at 15:01, Philipp Tomsich <philipp.tomsich@vrull.eu> >>>> wrote: >>>>>>>>> >>>>>>>>> We did touch on this in our coordination call a few weeks ago: the >>>>>>>>> grouping under mmu and the bool-entries were chosen because of >>>> their >>>>>>>>> similarity to other extensions (i.e. for Zb[abcs] there >>>> could/should >>>>>>>>> be a bool-entry under each cpu-node — for some Zv* entries a >>>> subnode >>>>>>>>> might be needed with further parameters). >>>>>>>>> >>>>>>>>> The string-based approach (as in the originally proposed >>>> "mmu-type=") >>>>>>>>> would like not scale with the proliferation of small & modular >>>>>>>>> extensions. >>>>>>>> >>>>>>>> I don’t see why the Sv* extensions need to be under an mmu node >>>> then, >>>>>>>> unless the intent is that every extension be grouped under a >>>> sub-node >>>>>>>> (which doesn’t seem viable due to extensions like Zbk*, unless you >>>>>>>> group by Ss, Sv and Z)? >>>>>>>> >>>>>>> >>>>>>> It shouldn't be. All the ISA extensions (i.e. standard, supervisor & >>>> hypervisor) >>>>>>> with prefix S,Z,H should be kept separate in a separate node for easy >>>>>>> parsing. >>>>>> >>>>>> "Easy parsing" is not quite convincing. >>>>> >>>>> The device tree need to carry a very long "riscv,isa" string. The >>>>> parser need to parse >>>>> that string in memory as well. >>>>> >>>>>> >>>>>> There's a reason other than that I made RFC PATCH to parse >>>>>> multi-letter extensions: >>>>>> >>>>>> v1: < >>>> http://lists.infradead.org/pipermail/linux-riscv/2021-November/010252.html >>>>> >>>>>> v2: < >>>> http://lists.infradead.org/pipermail/linux-riscv/2021-November/010350.html >>>>> >>>>>> >>>>> >>>>> It's on my todo list to review the series. I think we can work >>>>> together to propose a better framework for riscv isa extensions. >>>>> >>>>>> (note: those patches will break RISC-V KVM because of possible ISA >>>>>> Manual inconsistency and discussion/resolution needed) >>>>>> >>>>>> (...continued below...) >>>>>> >>>>>>> >>>>>>> "riscv,isa" dt property will not scale at all. Just look at the few >>>>>>> extensions that were ratified this year >>>>>>> and Linux kernel needs to support them. >>>>>>> >>>>>>> "Sscofpmf", "Svpbmt", "Zicbom" >>>>>>> >>>>>>>> Also, what is going to happen to the current riscv,isa? Will that >>>>>>>> continue to exist and duplicate the info, or will kernels be >>>> required >>>>>>>> to reconstruct the string themselves if they want to display it to >>>>>>>> users? >>>>>>>> >>>>> >>>>> Sorry. I missed this question earlier. See my answer below. >>>>> >>>>>>> >>>>>>> This is my personal preference: >>>>>>> riscv,isa will continue to base Standard ISA extensions that have >>>>>>> single letter extensions. >>>>>>> >>>>>>> This new DT node will encode all the non-single letter extensions. >>>>>>> I am not sure if it should include some provisions for custom >>>>>>> extensions starting with X because >>>>>>> that will be platform specific. >>>>>>> >>>>>>> Again, this is just my personal preference. I will try to send a >>>> patch >>>>>>> soon so that we can initiate a broader >>>>>>> discussion of the scheme and agree/disagree on something. >>>>>> >>>>>> For supervisor-only extensions like "Svpbmt", new DT node would be a >>>>>> reasonable solution (and I would not directly object about that node). >>>>>> >>>>>> However, there's many multi-letter extensions that are useful for >>>>>> user mode. Because "riscv,isa" is exposed via sysfs and procfs >>>>>> (/proc/cpuinfo), it can be really helpful to have multi-letter >>>>> >>>>> Irrespective of the method chosen to parse the device tree in kernel, >>>>> we need to provide the extension information to the userspace. >>>>> >>>>> This is what I have in mind. An individual row with comma separated >>>>> extension names for each type of extensions (Ss, Sv, Sh) >>>>> after the base extension (rv64imafdc) in /proc/cpuinfo output. I am >>>>> open to other ideas as well. >>>>> >>>>> isa rv64imafdc >>>>> isa-ext-Sv Svpbmt >>>>> isa-ext-Ss Sscofpmf >>>>> isa-ext-Sh <hypervisor related extensions> >>>>> isa-ext-Z Zicbom >>>>> >>>>> We can even explicitly name the extensions after isa-ext. However, it >>>>> may be necessary and too long. >>>> >>>> Aren't other architectures just using a flags [x86] or features [arm64] >>>> line in cpuinfo to expose the available additional cpu features >>>> as a space-separated list? >>>> >>>> So you could also just do something similar like >>>> isa: rv64imafdc >>>> isa-ext: Svpbmt Sscofpmf foo bar >>>> >>>> >>> A space separated list is also fine by me. >>> Should we keep all the extensions as one row or split based on the type of >>> extensions (Ss, Sv, Sh,)? >>> >>> When I look at the flags in x86, my eyes hurt badly ;) >> >> On arm64 >> Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid >> >> or on arm32 >> Features : half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm >> >> >>> That's why I suggested splitting by type of extensions to improve >>> readability. >> >> Though I guess with that split you introduce more requirements on userspace? >> Because things that parse cpuinfo (think some python library) will need to >> be updated when some new extension category surfaces? >> >> >> >>>> That would make a nice compromise between length and readability >>>> by users I guess? >>>> >>>> >>>> Heiko >>>> >>>>> I guess you prefer to directly print the entire "riscv,isa" string in >>>>> "isa" row in /proc/cpuinfo output. >>>>> It is probably okay with the current number of extensions available >>>>> today. However, it will become so long string >>>>> in the future that it has to be broken into multiple lines. >>>>> >>>>>> extensions. Also, current version of Spike, a RISC-V ISA Simulator >>>>>> puts all multi-letter extensions in "riscv,isa" and I thought this is >>>>>> intended. >>>>>> >>>>>> My preference: >>>>>> (1) Allow having multi-letter extensions and versions in "riscv,isa" >>>>>> (2) Adding new DT node for supervisor-related extensions would be >>>>>> reasonable (but I don't strongly agree/disagree). >>>>>> >>>>>> Thanks, >>>>>> Tsukasa >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> As a FreeBSD developer I’m obviously not a part of many of these >>>>>>>> discussions, but what the Linux community imposes as the device tree >>>>>>>> bindings has a real impact on us. >>>>>>>> >>>>>>>> Jess >>>>>>>> >>>>>>>>> On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com> >>>> wrote: >>>>>>>>>> >>>>>>>>>> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica >>>> Clarke: >>>>>>>>>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> >>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko >>>> Stübner: >>>>>>>>>>>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich >>>> Schuchardt: >>>>>>>>>>>>>>> On 11/29/21 02:40, wefu@redhat.com wrote: >>>>>>>>>>>>>>>> From: Wei Fu <wefu@redhat.com> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Previous patch has added svpbmt in arch/riscv and add >>>> "riscv,svpmbt" >>>>>>>>>>>>>>>> in the DT mmu node. Update dt-bindings related property >>>> here. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Signed-off-by: Wei Fu <wefu@redhat.com> >>>>>>>>>>>>>>>> Co-developed-by: Guo Ren <guoren@kernel.org> >>>>>>>>>>>>>>>> Signed-off-by: Guo Ren <guoren@kernel.org> >>>>>>>>>>>>>>>> Cc: Anup Patel <anup@brainfault.org> >>>>>>>>>>>>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com> >>>>>>>>>>>>>>>> Cc: Rob Herring <robh+dt@kernel.org> >>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 >>>> ++++++++++ >>>>>>>>>>>>>>>> 1 file changed, 10 insertions(+) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> diff --git >>>> a/Documentation/devicetree/bindings/riscv/cpus.yaml >>>> b/Documentation/devicetree/bindings/riscv/cpus.yaml >>>>>>>>>>>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644 >>>>>>>>>>>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml >>>>>>>>>>>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml >>>>>>>>>>>>>>>> @@ -63,6 +63,16 @@ properties: >>>>>>>>>>>>>>>> - riscv,sv48 >>>>>>>>>>>>>>>> - riscv,none >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> + mmu: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu >>>> before >>>>>>>>>>>>>>> mmu-type? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> + description: >>>>>>>>>>>>>>>> + Describes the CPU's MMU Standard Extensions support. >>>>>>>>>>>>>>>> + These values originate from the RISC-V Privileged >>>>>>>>>>>>>>>> + Specification document, available from >>>>>>>>>>>>>>>> + https://riscv.org/specifications/ >>>>>>>>>>>>>>>> + $ref: '/schemas/types.yaml#/definitions/string' >>>>>>>>>>>>>>>> + enum: >>>>>>>>>>>>>>>> + - riscv,svpmbt >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The privileged specification has multiple MMU related >>>> extensions: >>>>>>>>>>>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this >>>> enum? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I remember in some earlier version some way back there was the >>>>>>>>>>>>>> suggestion of using a sub-node instead and then adding boolean >>>>>>>>>>>>>> properties for the supported extensions. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Aka something like >>>>>>>>>>>>>> mmu { >>>>>>>>>>>>>> riscv,svpbmt; >>>>>>>>>>>>>> }; >>>>>>>>>>>>> >>>>>>>>>>>>> For the record, I'm talking about the mail from september >>>>>>>>>>>>> >>>> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/ >>>>>>>>>>>>> >>>>>>>>>>>>> So having a sub-node would make adding future extensions >>>>>>>>>>>>> way nicer. >>>>>>>>>>>> >>>>>>>>>>>> Svpbmt is just an ISA extension, and should be treated like any >>>> other. >>>>>>>>>>>> Let’s not invent two different ways of representing that in the >>>> device >>>>>>>>>>>> tree. >>>>>>>>>>> >>>>>>>>>>> Heinrich asked how the other extensions should be handled >>>>>>>>>>> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with >>>> these? >>>>>>>>>> >>>>>>>>>> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may >>>> not be >>>>>>>>>> a concrete plan for that yet, but that means you should speak >>>> with the >>>>>>>>>> people involved with such extensions and come up with something >>>>>>>>>> appropriate together. >>>>>>>>>> >>>>>>>>>> Jess >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> linux-riscv mailing list >>>>>>>> linux-riscv@lists.infradead.org >>>>>>>> http://lists.infradead.org/mailman/listinfo/linux-riscv >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> Atish >>>>>>> >>>>>>> _______________________________________________ >>>>>>> linux-riscv mailing list >>>>>>> linux-riscv@lists.infradead.org >>>>>>> http://lists.infradead.org/mailman/listinfo/linux-riscv >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> >> >> ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt 2021-12-01 8:15 ` Atish Patra 2021-12-01 8:30 ` Heiko Stübner @ 2021-12-02 1:31 ` Tsukasa OI 2021-12-02 1:55 ` Atish Patra 1 sibling, 1 reply; 35+ messages in thread From: Tsukasa OI @ 2021-12-02 1:31 UTC (permalink / raw) To: Atish Patra Cc: Jessica Clarke, Philipp Tomsich, Heiko Stübner, linux-riscv, Wei Fu, linux-kernel@vger.kernel.org List, taiten.peng, Aniket Ponkshe, Gordan Markus, Guo Ren, Arnd Bergmann, Chen-Yu Tsai, Maxime Ripard, Dan Lustig, Greg Favor, Andrea Mondelli, Jonathan Behrens, Xinhaoqu, Bill Huffman, Nick Kossifidis, Allen Baum, Josh Scheid, Richard Trauben, Anup Patel, Rob Herring, Anup Patel, atishp04, Palmer Dabbelt, Guo Ren, Christoph Müllner, Christoph Hellwig, liush, Wei Wu, Drew Fustini, Heinrich Schuchardt On 2021/12/01 17:15, Atish Patra wrote: > On Tue, Nov 30, 2021 at 7:06 PM Tsukasa OI <research_trasio@irq.a4lg.com> wrote: >> >> On 2021/12/01 10:21, Atish Patra wrote: >>> On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <jrtc27@jrtc27.com> wrote: >>>> >>>> On 30 Nov 2021, at 15:01, Philipp Tomsich <philipp.tomsich@vrull.eu> wrote: >>>>> >>>>> We did touch on this in our coordination call a few weeks ago: the >>>>> grouping under mmu and the bool-entries were chosen because of their >>>>> similarity to other extensions (i.e. for Zb[abcs] there could/should >>>>> be a bool-entry under each cpu-node — for some Zv* entries a subnode >>>>> might be needed with further parameters). >>>>> >>>>> The string-based approach (as in the originally proposed "mmu-type=") >>>>> would like not scale with the proliferation of small & modular >>>>> extensions. >>>> >>>> I don’t see why the Sv* extensions need to be under an mmu node then, >>>> unless the intent is that every extension be grouped under a sub-node >>>> (which doesn’t seem viable due to extensions like Zbk*, unless you >>>> group by Ss, Sv and Z)? >>>> >>> >>> It shouldn't be. All the ISA extensions (i.e. standard, supervisor & hypervisor) >>> with prefix S,Z,H should be kept separate in a separate node for easy >>> parsing. >> >> "Easy parsing" is not quite convincing. > > The device tree need to carry a very long "riscv,isa" string. The > parser need to parse > that string in memory as well. > >> >> There's a reason other than that I made RFC PATCH to parse >> multi-letter extensions: >> >> v1: <http://lists.infradead.org/pipermail/linux-riscv/2021-November/010252.html> >> v2: <http://lists.infradead.org/pipermail/linux-riscv/2021-November/010350.html> >> > > It's on my todo list to review the series. I think we can work > together to propose a better framework for riscv isa extensions. Thanks. I will submit RFC PATCH v3 today so that we can start a healthy discussion. I apologize that I missed so many points and there's a lot things to learn. As far as I know, if we make new DT nodes for separate extensions, we have to (at least) synchronize the implementation with Spike. This simulator accepts ISA string through `--isa' option and (by default) puts entire ISA string into the device tree as "riscv,isa" (after expansion "G" -> "IMAFD"). Of course, it includes "Svpbmt", in which we are discussing. spike --isa=rv64g_zba_zbb_zbc_zbs_svinval_svnapot_svpbmt ... I am just wondering whether breaking this behavior would worth it. IMHO, we could create new DT nodes **and** in addition, we can possibly use "riscv,isa" as a fallback. I'm not sure that this would work (just changing Spike might be better) but I ...think... it's worth discussing it. > >> (note: those patches will break RISC-V KVM because of possible ISA >> Manual inconsistency and discussion/resolution needed) >> >> (...continued below...) >> >>> >>> "riscv,isa" dt property will not scale at all. Just look at the few >>> extensions that were ratified this year >>> and Linux kernel needs to support them. >>> >>> "Sscofpmf", "Svpbmt", "Zicbom" >>> >>>> Also, what is going to happen to the current riscv,isa? Will that >>>> continue to exist and duplicate the info, or will kernels be required >>>> to reconstruct the string themselves if they want to display it to >>>> users? >>>> > > Sorry. I missed this question earlier. See my answer below. > >>> >>> This is my personal preference: >>> riscv,isa will continue to base Standard ISA extensions that have >>> single letter extensions. >>> >>> This new DT node will encode all the non-single letter extensions. >>> I am not sure if it should include some provisions for custom >>> extensions starting with X because >>> that will be platform specific. >>> >>> Again, this is just my personal preference. I will try to send a patch >>> soon so that we can initiate a broader >>> discussion of the scheme and agree/disagree on something. >> >> For supervisor-only extensions like "Svpbmt", new DT node would be a >> reasonable solution (and I would not directly object about that node). >> >> However, there's many multi-letter extensions that are useful for >> user mode. Because "riscv,isa" is exposed via sysfs and procfs >> (/proc/cpuinfo), it can be really helpful to have multi-letter > > Irrespective of the method chosen to parse the device tree in kernel, > we need to provide the extension information to the userspace. > > This is what I have in mind. An individual row with comma separated > extension names for each type of extensions (Ss, Sv, Sh) > after the base extension (rv64imafdc) in /proc/cpuinfo output. I am > open to other ideas as well. > > isa rv64imafdc > isa-ext-Sv Svpbmt > isa-ext-Ss Sscofpmf > isa-ext-Sh <hypervisor related extensions> > isa-ext-Z Zicbom > > We can even explicitly name the extensions after isa-ext. However, it > may be necessary and too long. > > I guess you prefer to directly print the entire "riscv,isa" string in > "isa" row in /proc/cpuinfo output. > It is probably okay with the current number of extensions available > today. However, it will become so long string > in the future that it has to be broken into multiple lines. > >> extensions. Also, current version of Spike, a RISC-V ISA Simulator >> puts all multi-letter extensions in "riscv,isa" and I thought this is >> intended. >> >> My preference: >> (1) Allow having multi-letter extensions and versions in "riscv,isa" >> (2) Adding new DT node for supervisor-related extensions would be >> reasonable (but I don't strongly agree/disagree). >> >> Thanks, >> Tsukasa >> >>> >>> >>> >>>> As a FreeBSD developer I’m obviously not a part of many of these >>>> discussions, but what the Linux community imposes as the device tree >>>> bindings has a real impact on us. >>>> >>>> Jess >>>> >>>>> On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com> wrote: >>>>>> >>>>>> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke: >>>>>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote: >>>>>>>>> >>>>>>>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner: >>>>>>>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt: >>>>>>>>>>> On 11/29/21 02:40, wefu@redhat.com wrote: >>>>>>>>>>>> From: Wei Fu <wefu@redhat.com> >>>>>>>>>>>> >>>>>>>>>>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt" >>>>>>>>>>>> in the DT mmu node. Update dt-bindings related property here. >>>>>>>>>>>> >>>>>>>>>>>> Signed-off-by: Wei Fu <wefu@redhat.com> >>>>>>>>>>>> Co-developed-by: Guo Ren <guoren@kernel.org> >>>>>>>>>>>> Signed-off-by: Guo Ren <guoren@kernel.org> >>>>>>>>>>>> Cc: Anup Patel <anup@brainfault.org> >>>>>>>>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com> >>>>>>>>>>>> Cc: Rob Herring <robh+dt@kernel.org> >>>>>>>>>>>> --- >>>>>>>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++ >>>>>>>>>>>> 1 file changed, 10 insertions(+) >>>>>>>>>>>> >>>>>>>>>>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml >>>>>>>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644 >>>>>>>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml >>>>>>>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml >>>>>>>>>>>> @@ -63,6 +63,16 @@ properties: >>>>>>>>>>>> - riscv,sv48 >>>>>>>>>>>> - riscv,none >>>>>>>>>>>> >>>>>>>>>>>> + mmu: >>>>>>>>>>> >>>>>>>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before >>>>>>>>>>> mmu-type? >>>>>>>>>>> >>>>>>>>>>>> + description: >>>>>>>>>>>> + Describes the CPU's MMU Standard Extensions support. >>>>>>>>>>>> + These values originate from the RISC-V Privileged >>>>>>>>>>>> + Specification document, available from >>>>>>>>>>>> + https://riscv.org/specifications/ >>>>>>>>>>>> + $ref: '/schemas/types.yaml#/definitions/string' >>>>>>>>>>>> + enum: >>>>>>>>>>>> + - riscv,svpmbt >>>>>>>>>>> >>>>>>>>>>> The privileged specification has multiple MMU related extensions: >>>>>>>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum? >>>>>>>>>> >>>>>>>>>> I remember in some earlier version some way back there was the >>>>>>>>>> suggestion of using a sub-node instead and then adding boolean >>>>>>>>>> properties for the supported extensions. >>>>>>>>>> >>>>>>>>>> Aka something like >>>>>>>>>> mmu { >>>>>>>>>> riscv,svpbmt; >>>>>>>>>> }; >>>>>>>>> >>>>>>>>> For the record, I'm talking about the mail from september >>>>>>>>> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/ >>>>>>>>> >>>>>>>>> So having a sub-node would make adding future extensions >>>>>>>>> way nicer. >>>>>>>> >>>>>>>> Svpbmt is just an ISA extension, and should be treated like any other. >>>>>>>> Let’s not invent two different ways of representing that in the device >>>>>>>> tree. >>>>>>> >>>>>>> Heinrich asked how the other extensions should be handled >>>>>>> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with these? >>>>>> >>>>>> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may not be >>>>>> a concrete plan for that yet, but that means you should speak with the >>>>>> people involved with such extensions and come up with something >>>>>> appropriate together. >>>>>> >>>>>> Jess >>>>>> >>>> >>>> >>>> _______________________________________________ >>>> linux-riscv mailing list >>>> linux-riscv@lists.infradead.org >>>> http://lists.infradead.org/mailman/listinfo/linux-riscv >>> >>> >>> >>> -- >>> Regards, >>> Atish >>> >>> _______________________________________________ >>> linux-riscv mailing list >>> linux-riscv@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/linux-riscv >>> > > > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt 2021-12-02 1:31 ` Tsukasa OI @ 2021-12-02 1:55 ` Atish Patra 0 siblings, 0 replies; 35+ messages in thread From: Atish Patra @ 2021-12-02 1:55 UTC (permalink / raw) To: Tsukasa OI Cc: Jessica Clarke, Philipp Tomsich, Heiko Stübner, linux-riscv, Wei Fu, linux-kernel@vger.kernel.org List, taiten.peng, Aniket Ponkshe, Gordan Markus, Guo Ren, Arnd Bergmann, Chen-Yu Tsai, Maxime Ripard, Dan Lustig, Greg Favor, Andrea Mondelli, Jonathan Behrens, Xinhaoqu, Bill Huffman, Nick Kossifidis, Allen Baum, Josh Scheid, Richard Trauben, Anup Patel, Rob Herring, Anup Patel, atishp04, Palmer Dabbelt, Guo Ren, Christoph Müllner, Christoph Hellwig, liush, Wei Wu, Drew Fustini, Heinrich Schuchardt On Wed, Dec 1, 2021 at 5:31 PM Tsukasa OI <research_trasio@irq.a4lg.com> wrote: > > On 2021/12/01 17:15, Atish Patra wrote: > > On Tue, Nov 30, 2021 at 7:06 PM Tsukasa OI <research_trasio@irq.a4lg.com> wrote: > >> > >> On 2021/12/01 10:21, Atish Patra wrote: > >>> On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <jrtc27@jrtc27.com> wrote: > >>>> > >>>> On 30 Nov 2021, at 15:01, Philipp Tomsich <philipp.tomsich@vrull.eu> wrote: > >>>>> > >>>>> We did touch on this in our coordination call a few weeks ago: the > >>>>> grouping under mmu and the bool-entries were chosen because of their > >>>>> similarity to other extensions (i.e. for Zb[abcs] there could/should > >>>>> be a bool-entry under each cpu-node — for some Zv* entries a subnode > >>>>> might be needed with further parameters). > >>>>> > >>>>> The string-based approach (as in the originally proposed "mmu-type=") > >>>>> would like not scale with the proliferation of small & modular > >>>>> extensions. > >>>> > >>>> I don’t see why the Sv* extensions need to be under an mmu node then, > >>>> unless the intent is that every extension be grouped under a sub-node > >>>> (which doesn’t seem viable due to extensions like Zbk*, unless you > >>>> group by Ss, Sv and Z)? > >>>> > >>> > >>> It shouldn't be. All the ISA extensions (i.e. standard, supervisor & hypervisor) > >>> with prefix S,Z,H should be kept separate in a separate node for easy > >>> parsing. > >> > >> "Easy parsing" is not quite convincing. > > > > The device tree need to carry a very long "riscv,isa" string. The > > parser need to parse > > that string in memory as well. > > > >> > >> There's a reason other than that I made RFC PATCH to parse > >> multi-letter extensions: > >> > >> v1: <http://lists.infradead.org/pipermail/linux-riscv/2021-November/010252.html> > >> v2: <http://lists.infradead.org/pipermail/linux-riscv/2021-November/010350.html> > >> > > > > It's on my todo list to review the series. I think we can work > > together to propose a better framework for riscv isa extensions. > > Thanks. I will submit RFC PATCH v3 today so that we can start a healthy > discussion. I apologize that I missed so many points and there's a lot > things to learn. > > As far as I know, if we make new DT nodes for separate extensions, we have > to (at least) synchronize the implementation with Spike. This simulator > accepts ISA string through `--isa' option and (by default) puts entire ISA > string into the device tree as "riscv,isa" (after expansion > "G" -> "IMAFD"). > > Of course, it includes "Svpbmt", in which we are discussing. > > spike --isa=rv64g_zba_zbb_zbc_zbs_svinval_svnapot_svpbmt ... > > I am just wondering whether breaking this behavior would worth it. > > IMHO, we could create new DT nodes **and** in addition, we can possibly > use "riscv,isa" as a fallback. I don't think that would be necessary. We can just fix the spike implementation if a separate DT node approach is accepted upstream. The device tree formation is Linux specific. Given that we will have a well defined DT binding for the new DT node, it is enough to change the spike. > I'm not sure that this would work (just changing Spike might be better) > but I ...think... it's worth discussing it. > > > > >> (note: those patches will break RISC-V KVM because of possible ISA > >> Manual inconsistency and discussion/resolution needed) > >> > >> (...continued below...) > >> > >>> > >>> "riscv,isa" dt property will not scale at all. Just look at the few > >>> extensions that were ratified this year > >>> and Linux kernel needs to support them. > >>> > >>> "Sscofpmf", "Svpbmt", "Zicbom" > >>> > >>>> Also, what is going to happen to the current riscv,isa? Will that > >>>> continue to exist and duplicate the info, or will kernels be required > >>>> to reconstruct the string themselves if they want to display it to > >>>> users? > >>>> > > > > Sorry. I missed this question earlier. See my answer below. > > > >>> > >>> This is my personal preference: > >>> riscv,isa will continue to base Standard ISA extensions that have > >>> single letter extensions. > >>> > >>> This new DT node will encode all the non-single letter extensions. > >>> I am not sure if it should include some provisions for custom > >>> extensions starting with X because > >>> that will be platform specific. > >>> > >>> Again, this is just my personal preference. I will try to send a patch > >>> soon so that we can initiate a broader > >>> discussion of the scheme and agree/disagree on something. > >> > >> For supervisor-only extensions like "Svpbmt", new DT node would be a > >> reasonable solution (and I would not directly object about that node). > >> > >> However, there's many multi-letter extensions that are useful for > >> user mode. Because "riscv,isa" is exposed via sysfs and procfs > >> (/proc/cpuinfo), it can be really helpful to have multi-letter > > > > Irrespective of the method chosen to parse the device tree in kernel, > > we need to provide the extension information to the userspace. > > > > This is what I have in mind. An individual row with comma separated > > extension names for each type of extensions (Ss, Sv, Sh) > > after the base extension (rv64imafdc) in /proc/cpuinfo output. I am > > open to other ideas as well. > > > > isa rv64imafdc > > isa-ext-Sv Svpbmt > > isa-ext-Ss Sscofpmf > > isa-ext-Sh <hypervisor related extensions> > > isa-ext-Z Zicbom > > > > We can even explicitly name the extensions after isa-ext. However, it > > may be necessary and too long. > > > > I guess you prefer to directly print the entire "riscv,isa" string in > > "isa" row in /proc/cpuinfo output. > > It is probably okay with the current number of extensions available > > today. However, it will become so long string > > in the future that it has to be broken into multiple lines. > > > >> extensions. Also, current version of Spike, a RISC-V ISA Simulator > >> puts all multi-letter extensions in "riscv,isa" and I thought this is > >> intended. > >> > >> My preference: > >> (1) Allow having multi-letter extensions and versions in "riscv,isa" > >> (2) Adding new DT node for supervisor-related extensions would be > >> reasonable (but I don't strongly agree/disagree). > >> > >> Thanks, > >> Tsukasa > >> > >>> > >>> > >>> > >>>> As a FreeBSD developer I’m obviously not a part of many of these > >>>> discussions, but what the Linux community imposes as the device tree > >>>> bindings has a real impact on us. > >>>> > >>>> Jess > >>>> > >>>>> On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com> wrote: > >>>>>> > >>>>>> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote: > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke: > >>>>>>>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote: > >>>>>>>>> > >>>>>>>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner: > >>>>>>>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt: > >>>>>>>>>>> On 11/29/21 02:40, wefu@redhat.com wrote: > >>>>>>>>>>>> From: Wei Fu <wefu@redhat.com> > >>>>>>>>>>>> > >>>>>>>>>>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt" > >>>>>>>>>>>> in the DT mmu node. Update dt-bindings related property here. > >>>>>>>>>>>> > >>>>>>>>>>>> Signed-off-by: Wei Fu <wefu@redhat.com> > >>>>>>>>>>>> Co-developed-by: Guo Ren <guoren@kernel.org> > >>>>>>>>>>>> Signed-off-by: Guo Ren <guoren@kernel.org> > >>>>>>>>>>>> Cc: Anup Patel <anup@brainfault.org> > >>>>>>>>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com> > >>>>>>>>>>>> Cc: Rob Herring <robh+dt@kernel.org> > >>>>>>>>>>>> --- > >>>>>>>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++ > >>>>>>>>>>>> 1 file changed, 10 insertions(+) > >>>>>>>>>>>> > >>>>>>>>>>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml > >>>>>>>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644 > >>>>>>>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml > >>>>>>>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml > >>>>>>>>>>>> @@ -63,6 +63,16 @@ properties: > >>>>>>>>>>>> - riscv,sv48 > >>>>>>>>>>>> - riscv,none > >>>>>>>>>>>> > >>>>>>>>>>>> + mmu: > >>>>>>>>>>> > >>>>>>>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before > >>>>>>>>>>> mmu-type? > >>>>>>>>>>> > >>>>>>>>>>>> + description: > >>>>>>>>>>>> + Describes the CPU's MMU Standard Extensions support. > >>>>>>>>>>>> + These values originate from the RISC-V Privileged > >>>>>>>>>>>> + Specification document, available from > >>>>>>>>>>>> + https://riscv.org/specifications/ > >>>>>>>>>>>> + $ref: '/schemas/types.yaml#/definitions/string' > >>>>>>>>>>>> + enum: > >>>>>>>>>>>> + - riscv,svpmbt > >>>>>>>>>>> > >>>>>>>>>>> The privileged specification has multiple MMU related extensions: > >>>>>>>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum? > >>>>>>>>>> > >>>>>>>>>> I remember in some earlier version some way back there was the > >>>>>>>>>> suggestion of using a sub-node instead and then adding boolean > >>>>>>>>>> properties for the supported extensions. > >>>>>>>>>> > >>>>>>>>>> Aka something like > >>>>>>>>>> mmu { > >>>>>>>>>> riscv,svpbmt; > >>>>>>>>>> }; > >>>>>>>>> > >>>>>>>>> For the record, I'm talking about the mail from september > >>>>>>>>> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/ > >>>>>>>>> > >>>>>>>>> So having a sub-node would make adding future extensions > >>>>>>>>> way nicer. > >>>>>>>> > >>>>>>>> Svpbmt is just an ISA extension, and should be treated like any other. > >>>>>>>> Let’s not invent two different ways of representing that in the device > >>>>>>>> tree. > >>>>>>> > >>>>>>> Heinrich asked how the other extensions should be handled > >>>>>>> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with these? > >>>>>> > >>>>>> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may not be > >>>>>> a concrete plan for that yet, but that means you should speak with the > >>>>>> people involved with such extensions and come up with something > >>>>>> appropriate together. > >>>>>> > >>>>>> Jess > >>>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> linux-riscv mailing list > >>>> linux-riscv@lists.infradead.org > >>>> http://lists.infradead.org/mailman/listinfo/linux-riscv > >>> > >>> > >>> > >>> -- > >>> Regards, > >>> Atish > >>> > >>> _______________________________________________ > >>> linux-riscv mailing list > >>> linux-riscv@lists.infradead.org > >>> http://lists.infradead.org/mailman/listinfo/linux-riscv > >>> > > > > > > -- Regards, Atish ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt 2021-12-01 1:21 ` Atish Patra 2021-12-01 3:06 ` Tsukasa OI @ 2021-12-01 13:28 ` Heiko Stübner 2021-12-02 1:59 ` Atish Patra 1 sibling, 1 reply; 35+ messages in thread From: Heiko Stübner @ 2021-12-01 13:28 UTC (permalink / raw) To: Jessica Clarke, Atish Patra Cc: Philipp Tomsich, linux-riscv, Wei Fu, linux-kernel@vger.kernel.org List, taiten.peng, Aniket Ponkshe, Gordan Markus, Guo Ren, Arnd Bergmann, Chen-Yu Tsai, Maxime Ripard, Dan Lustig, Greg Favor, Andrea Mondelli, Jonathan Behrens, Xinhaoqu, Bill Huffman, Nick Kossifidis, Allen Baum, Josh Scheid, Richard Trauben, Anup Patel, Rob Herring, Anup Patel, atishp04, Palmer Dabbelt, Guo Ren, Christoph Müllner, Christoph Hellwig, liush, Wei Wu, Drew Fustini, Heinrich Schuchardt Hi Atish, Am Mittwoch, 1. Dezember 2021, 02:21:46 CET schrieb Atish Patra: > On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <jrtc27@jrtc27.com> wrote: > > > > On 30 Nov 2021, at 15:01, Philipp Tomsich <philipp.tomsich@vrull.eu> wrote: > > > > > > We did touch on this in our coordination call a few weeks ago: the > > > grouping under mmu and the bool-entries were chosen because of their > > > similarity to other extensions (i.e. for Zb[abcs] there could/should > > > be a bool-entry under each cpu-node — for some Zv* entries a subnode > > > might be needed with further parameters). > > > > > > The string-based approach (as in the originally proposed "mmu-type=") > > > would like not scale with the proliferation of small & modular > > > extensions. > > > > I don’t see why the Sv* extensions need to be under an mmu node then, > > unless the intent is that every extension be grouped under a sub-node > > (which doesn’t seem viable due to extensions like Zbk*, unless you > > group by Ss, Sv and Z)? > > > > It shouldn't be. All the ISA extensions (i.e. standard, supervisor & hypervisor) > with prefix S,Z,H should be kept separate in a separate node for easy > parsing. > > "riscv,isa" dt property will not scale at all. Just look at the few > extensions that were ratified this year > and Linux kernel needs to support them. > > "Sscofpmf", "Svpbmt", "Zicbom" > > > Also, what is going to happen to the current riscv,isa? Will that > > continue to exist and duplicate the info, or will kernels be required > > to reconstruct the string themselves if they want to display it to > > users? > > > > This is my personal preference: > riscv,isa will continue to base Standard ISA extensions that have > single letter extensions. > > This new DT node will encode all the non-single letter extensions. > I am not sure if it should include some provisions for custom > extensions starting with X because > that will be platform specific. > > Again, this is just my personal preference. I will try to send a patch > soon so that we can initiate a broader > discussion of the scheme and agree/disagree on something. that would be really helpful, as it currently looks like we have a number of different points-of-view so discussing an actual implementation will probably make things a lot easier compared to dancing around theoretic cases :-) . Out of curiosity, how soon is "soon" ? :-D Heiko > > As a FreeBSD developer I’m obviously not a part of many of these > > discussions, but what the Linux community imposes as the device tree > > bindings has a real impact on us. > > > > Jess > > > > > On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com> wrote: > > >> > > >> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote: > > >>> > > >>> Hi, > > >>> > > >>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke: > > >>>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote: > > >>>>> > > >>>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner: > > >>>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt: > > >>>>>>> On 11/29/21 02:40, wefu@redhat.com wrote: > > >>>>>>>> From: Wei Fu <wefu@redhat.com> > > >>>>>>>> > > >>>>>>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt" > > >>>>>>>> in the DT mmu node. Update dt-bindings related property here. > > >>>>>>>> > > >>>>>>>> Signed-off-by: Wei Fu <wefu@redhat.com> > > >>>>>>>> Co-developed-by: Guo Ren <guoren@kernel.org> > > >>>>>>>> Signed-off-by: Guo Ren <guoren@kernel.org> > > >>>>>>>> Cc: Anup Patel <anup@brainfault.org> > > >>>>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com> > > >>>>>>>> Cc: Rob Herring <robh+dt@kernel.org> > > >>>>>>>> --- > > >>>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++ > > >>>>>>>> 1 file changed, 10 insertions(+) > > >>>>>>>> > > >>>>>>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml > > >>>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644 > > >>>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml > > >>>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml > > >>>>>>>> @@ -63,6 +63,16 @@ properties: > > >>>>>>>> - riscv,sv48 > > >>>>>>>> - riscv,none > > >>>>>>>> > > >>>>>>>> + mmu: > > >>>>>>> > > >>>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before > > >>>>>>> mmu-type? > > >>>>>>> > > >>>>>>>> + description: > > >>>>>>>> + Describes the CPU's MMU Standard Extensions support. > > >>>>>>>> + These values originate from the RISC-V Privileged > > >>>>>>>> + Specification document, available from > > >>>>>>>> + https://riscv.org/specifications/ > > >>>>>>>> + $ref: '/schemas/types.yaml#/definitions/string' > > >>>>>>>> + enum: > > >>>>>>>> + - riscv,svpmbt > > >>>>>>> > > >>>>>>> The privileged specification has multiple MMU related extensions: > > >>>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum? > > >>>>>> > > >>>>>> I remember in some earlier version some way back there was the > > >>>>>> suggestion of using a sub-node instead and then adding boolean > > >>>>>> properties for the supported extensions. > > >>>>>> > > >>>>>> Aka something like > > >>>>>> mmu { > > >>>>>> riscv,svpbmt; > > >>>>>> }; > > >>>>> > > >>>>> For the record, I'm talking about the mail from september > > >>>>> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/ > > >>>>> > > >>>>> So having a sub-node would make adding future extensions > > >>>>> way nicer. > > >>>> > > >>>> Svpbmt is just an ISA extension, and should be treated like any other. > > >>>> Let’s not invent two different ways of representing that in the device > > >>>> tree. > > >>> > > >>> Heinrich asked how the other extensions should be handled > > >>> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with these? > > >> > > >> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may not be > > >> a concrete plan for that yet, but that means you should speak with the > > >> people involved with such extensions and come up with something > > >> appropriate together. > > >> > > >> Jess > > >> > > > > > > _______________________________________________ > > linux-riscv mailing list > > linux-riscv@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-riscv > > > > -- > Regards, > Atish > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt 2021-12-01 13:28 ` Heiko Stübner @ 2021-12-02 1:59 ` Atish Patra 0 siblings, 0 replies; 35+ messages in thread From: Atish Patra @ 2021-12-02 1:59 UTC (permalink / raw) To: Heiko Stübner Cc: Jessica Clarke, Philipp Tomsich, linux-riscv, Wei Fu, linux-kernel@vger.kernel.org List, taiten.peng, Aniket Ponkshe, Gordan Markus, Guo Ren, Arnd Bergmann, Chen-Yu Tsai, Maxime Ripard, Dan Lustig, Greg Favor, Andrea Mondelli, Jonathan Behrens, Xinhaoqu, Bill Huffman, Nick Kossifidis, Allen Baum, Josh Scheid, Richard Trauben, Anup Patel, Rob Herring, Anup Patel, atishp04, Palmer Dabbelt, Guo Ren, Christoph Müllner, Christoph Hellwig, liush, Wei Wu, Drew Fustini, Heinrich Schuchardt On Wed, Dec 1, 2021 at 5:28 AM Heiko Stübner <heiko@sntech.de> wrote: > > Hi Atish, > > Am Mittwoch, 1. Dezember 2021, 02:21:46 CET schrieb Atish Patra: > > On Tue, Nov 30, 2021 at 8:13 AM Jessica Clarke <jrtc27@jrtc27.com> wrote: > > > > > > On 30 Nov 2021, at 15:01, Philipp Tomsich <philipp.tomsich@vrull.eu> wrote: > > > > > > > > We did touch on this in our coordination call a few weeks ago: the > > > > grouping under mmu and the bool-entries were chosen because of their > > > > similarity to other extensions (i.e. for Zb[abcs] there could/should > > > > be a bool-entry under each cpu-node — for some Zv* entries a subnode > > > > might be needed with further parameters). > > > > > > > > The string-based approach (as in the originally proposed "mmu-type=") > > > > would like not scale with the proliferation of small & modular > > > > extensions. > > > > > > I don’t see why the Sv* extensions need to be under an mmu node then, > > > unless the intent is that every extension be grouped under a sub-node > > > (which doesn’t seem viable due to extensions like Zbk*, unless you > > > group by Ss, Sv and Z)? > > > > > > > It shouldn't be. All the ISA extensions (i.e. standard, supervisor & hypervisor) > > with prefix S,Z,H should be kept separate in a separate node for easy > > parsing. > > > > "riscv,isa" dt property will not scale at all. Just look at the few > > extensions that were ratified this year > > and Linux kernel needs to support them. > > > > "Sscofpmf", "Svpbmt", "Zicbom" > > > > > Also, what is going to happen to the current riscv,isa? Will that > > > continue to exist and duplicate the info, or will kernels be required > > > to reconstruct the string themselves if they want to display it to > > > users? > > > > > > > This is my personal preference: > > riscv,isa will continue to base Standard ISA extensions that have > > single letter extensions. > > > > This new DT node will encode all the non-single letter extensions. > > I am not sure if it should include some provisions for custom > > extensions starting with X because > > that will be platform specific. > > > > Again, this is just my personal preference. I will try to send a patch > > soon so that we can initiate a broader > > discussion of the scheme and agree/disagree on something. > > that would be really helpful, as it currently looks like we have a number > of different points-of-view so discussing an actual implementation will > probably make things a lot easier compared to dancing around theoretic > cases :-) . > > Out of curiosity, how soon is "soon" ? :-D > I will be on vacation for next week and I need to wrap up a few other things before that. Thus, soon may not be the "soon" you are expecting ;). If you or Tsukasa have some free cycles, feel free to send the patch in the meantime. > > Heiko > > > > > As a FreeBSD developer I’m obviously not a part of many of these > > > discussions, but what the Linux community imposes as the device tree > > > bindings has a real impact on us. > > > > > > Jess > > > > > > > On Tue, 30 Nov 2021 at 14:59, Jessica Clarke <jrtc27@jrtc27.com> wrote: > > > >> > > > >> On 30 Nov 2021, at 13:27, Heiko Stübner <heiko@sntech.de> wrote: > > > >>> > > > >>> Hi, > > > >>> > > > >>> Am Dienstag, 30. November 2021, 14:17:41 CET schrieb Jessica Clarke: > > > >>>> On 30 Nov 2021, at 12:07, Heiko Stübner <heiko@sntech.de> wrote: > > > >>>>> > > > >>>>> Am Montag, 29. November 2021, 13:06:23 CET schrieb Heiko Stübner: > > > >>>>>> Am Montag, 29. November 2021, 09:54:39 CET schrieb Heinrich Schuchardt: > > > >>>>>>> On 11/29/21 02:40, wefu@redhat.com wrote: > > > >>>>>>>> From: Wei Fu <wefu@redhat.com> > > > >>>>>>>> > > > >>>>>>>> Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt" > > > >>>>>>>> in the DT mmu node. Update dt-bindings related property here. > > > >>>>>>>> > > > >>>>>>>> Signed-off-by: Wei Fu <wefu@redhat.com> > > > >>>>>>>> Co-developed-by: Guo Ren <guoren@kernel.org> > > > >>>>>>>> Signed-off-by: Guo Ren <guoren@kernel.org> > > > >>>>>>>> Cc: Anup Patel <anup@brainfault.org> > > > >>>>>>>> Cc: Palmer Dabbelt <palmer@dabbelt.com> > > > >>>>>>>> Cc: Rob Herring <robh+dt@kernel.org> > > > >>>>>>>> --- > > > >>>>>>>> Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++ > > > >>>>>>>> 1 file changed, 10 insertions(+) > > > >>>>>>>> > > > >>>>>>>> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml > > > >>>>>>>> index aa5fb64d57eb..9ff9cbdd8a85 100644 > > > >>>>>>>> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml > > > >>>>>>>> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml > > > >>>>>>>> @@ -63,6 +63,16 @@ properties: > > > >>>>>>>> - riscv,sv48 > > > >>>>>>>> - riscv,none > > > >>>>>>>> > > > >>>>>>>> + mmu: > > > >>>>>>> > > > >>>>>>> Shouldn't we keep the items be in alphabetic order, i.e. mmu before > > > >>>>>>> mmu-type? > > > >>>>>>> > > > >>>>>>>> + description: > > > >>>>>>>> + Describes the CPU's MMU Standard Extensions support. > > > >>>>>>>> + These values originate from the RISC-V Privileged > > > >>>>>>>> + Specification document, available from > > > >>>>>>>> + https://riscv.org/specifications/ > > > >>>>>>>> + $ref: '/schemas/types.yaml#/definitions/string' > > > >>>>>>>> + enum: > > > >>>>>>>> + - riscv,svpmbt > > > >>>>>>> > > > >>>>>>> The privileged specification has multiple MMU related extensions: > > > >>>>>>> Svnapot, Svpbmt, Svinval. Shall they all be modeled in this enum? > > > >>>>>> > > > >>>>>> I remember in some earlier version some way back there was the > > > >>>>>> suggestion of using a sub-node instead and then adding boolean > > > >>>>>> properties for the supported extensions. > > > >>>>>> > > > >>>>>> Aka something like > > > >>>>>> mmu { > > > >>>>>> riscv,svpbmt; > > > >>>>>> }; > > > >>>>> > > > >>>>> For the record, I'm talking about the mail from september > > > >>>>> https://lore.kernel.org/linux-riscv/CAAeLtUChjjzG+P8yg45GLZMJy5UR2K5RRBoLFVZhtOaZ5pPtEA@mail.gmail.com/ > > > >>>>> > > > >>>>> So having a sub-node would make adding future extensions > > > >>>>> way nicer. > > > >>>> > > > >>>> Svpbmt is just an ISA extension, and should be treated like any other. > > > >>>> Let’s not invent two different ways of representing that in the device > > > >>>> tree. > > > >>> > > > >>> Heinrich asked how the other extensions should be handled > > > >>> (Svnapot, Svpbmt, Svinval), so what do you suggest to do with these? > > > >> > > > >> Whatever is done for Zb[abcs], Zk*, Zv*, Zicbo*, etc. There may not be > > > >> a concrete plan for that yet, but that means you should speak with the > > > >> people involved with such extensions and come up with something > > > >> appropriate together. > > > >> > > > >> Jess > > > >> > > > > > > > > > _______________________________________________ > > > linux-riscv mailing list > > > linux-riscv@lists.infradead.org > > > http://lists.infradead.org/mailman/listinfo/linux-riscv > > > > > > > > -- > > Regards, > > Atish > > > > > > -- Regards, Atish ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt 2021-11-29 1:40 ` [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt wefu 2021-11-29 8:54 ` Heinrich Schuchardt @ 2021-11-30 18:45 ` Heiko Stübner 2021-12-01 2:58 ` Wei Fu 1 sibling, 1 reply; 35+ messages in thread From: Heiko Stübner @ 2021-11-30 18:45 UTC (permalink / raw) To: anup.patel, atishp04, palmer, guoren, christoph.muellner, philipp.tomsich, hch, liush, wefu, lazyparser, drew, linux-riscv Cc: linux-riscv, linux-kernel, taiten.peng, aniket.ponkshe, heinrich.schuchardt, gordan.markus, guoren, arnd, wens, maxime, dlustig, gfavor, andrea.mondelli, behrensj, xinhaoqu, huffman, mick, allen.baum, jscheid, rtrauben, Anup Patel, Rob Herring, wefu Am Montag, 29. November 2021, 02:40:06 CET schrieb wefu@redhat.com: > From: Wei Fu <wefu@redhat.com> > > Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt" > in the DT mmu node. Update dt-bindings related property here. > > Signed-off-by: Wei Fu <wefu@redhat.com> > Co-developed-by: Guo Ren <guoren@kernel.org> > Signed-off-by: Guo Ren <guoren@kernel.org> > Cc: Anup Patel <anup@brainfault.org> > Cc: Palmer Dabbelt <palmer@dabbelt.com> > Cc: Rob Herring <robh+dt@kernel.org> > --- > Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml > index aa5fb64d57eb..9ff9cbdd8a85 100644 > --- a/Documentation/devicetree/bindings/riscv/cpus.yaml > +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml > @@ -63,6 +63,16 @@ properties: > - riscv,sv48 > - riscv,none > > + mmu: > + description: > + Describes the CPU's MMU Standard Extensions support. > + These values originate from the RISC-V Privileged > + Specification document, available from > + https://riscv.org/specifications/ > + $ref: '/schemas/types.yaml#/definitions/string' > + enum: > + - riscv,svpmbt shouldn't that be "riscv,svpbmt" ? [the m is at the wrong location it seems] > + > riscv,isa: > description: > Identifies the specific RISC-V instruction set architecture > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt 2021-11-30 18:45 ` Heiko Stübner @ 2021-12-01 2:58 ` Wei Fu 0 siblings, 0 replies; 35+ messages in thread From: Wei Fu @ 2021-12-01 2:58 UTC (permalink / raw) To: Heiko Stübner Cc: Anup Patel, atishp04, Palmer Dabbelt, Guo Ren, Christoph Müllner, Philipp Tomsich, Christoph Hellwig, Liu Shaohua, Wei Wu (吴伟), Drew Fustini, linux-riscv, Linux Kernel Mailing List, taiten.peng, Aniket Ponkshe, Heinrich Schuchardt, Gordan Markus, Guo Ren, Arnd Bergmann, Chen-Yu Tsai, Maxime Ripard, Daniel Lustig, Greg Favor, Andrea Mondelli, Jonathan Behrens, Xinhaoqu, Bill Huffman, Nick Kossifidis, Allen Baum, Josh Scheid, Richard Trauben, Anup Patel, Rob Herring Hi Heiko, Thanks for your correction , this was my typo when I did the "sed" to replace the word. I need to make a V5 ASAP On Wed, Dec 1, 2021 at 2:46 AM Heiko Stübner <heiko@sntech.de> wrote: > > Am Montag, 29. November 2021, 02:40:06 CET schrieb wefu@redhat.com: > > From: Wei Fu <wefu@redhat.com> > > > > Previous patch has added svpbmt in arch/riscv and add "riscv,svpmbt" > > in the DT mmu node. Update dt-bindings related property here. > > > > Signed-off-by: Wei Fu <wefu@redhat.com> > > Co-developed-by: Guo Ren <guoren@kernel.org> > > Signed-off-by: Guo Ren <guoren@kernel.org> > > Cc: Anup Patel <anup@brainfault.org> > > Cc: Palmer Dabbelt <palmer@dabbelt.com> > > Cc: Rob Herring <robh+dt@kernel.org> > > --- > > Documentation/devicetree/bindings/riscv/cpus.yaml | 10 ++++++++++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml > > index aa5fb64d57eb..9ff9cbdd8a85 100644 > > --- a/Documentation/devicetree/bindings/riscv/cpus.yaml > > +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml > > @@ -63,6 +63,16 @@ properties: > > - riscv,sv48 > > - riscv,none > > > > + mmu: > > + description: > > + Describes the CPU's MMU Standard Extensions support. > > + These values originate from the RISC-V Privileged > > + Specification document, available from > > + https://riscv.org/specifications/ > > + $ref: '/schemas/types.yaml#/definitions/string' > > + enum: > > + - riscv,svpmbt > > shouldn't that be "riscv,svpbmt" ? [the m is at the wrong location it seems] > > > + > > riscv,isa: > > description: > > Identifies the specific RISC-V instruction set architecture > > > > > > ^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports 2021-11-29 1:40 [PATCH V4 0/2] riscv: add RISC-V Svpbmt Standard Extension supports wefu 2021-11-29 1:40 ` [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt wefu @ 2021-11-29 1:40 ` wefu 2021-11-29 10:48 ` Alexandre Ghiti ` (3 more replies) 2021-11-29 13:33 ` [PATCH V4 0/2] riscv: add RISC-V Svpbmt Standard Extension supports Jisheng Zhang 2 siblings, 4 replies; 35+ messages in thread From: wefu @ 2021-11-29 1:40 UTC (permalink / raw) To: anup.patel, atishp04, palmer, guoren, christoph.muellner, philipp.tomsich, hch, liush, wefu, lazyparser, drew Cc: linux-riscv, linux-kernel, taiten.peng, aniket.ponkshe, heinrich.schuchardt, gordan.markus, guoren, arnd, wens, maxime, dlustig, gfavor, andrea.mondelli, behrensj, xinhaoqu, huffman, mick, allen.baum, jscheid, rtrauben, Palmer Dabbelt, Atish Patra From: Wei Fu <wefu@redhat.com> This patch follows the standard pure RISC-V Svpbmt extension in privilege spec to solve the non-coherent SOC dma synchronization issues. Here is the svpbmt PTE format: | 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 N MT RSW D A G U X W R V ^ Of the Reserved bits [63:54] in a leaf PTE, the high bit is already allocated (as the N bit), so bits [62:61] are used as the MT (aka MemType) field. This field specifies one of three memory types that are close equivalents (or equivalent in effect) to the three main x86 and ARMv8 memory types - as shown in the following table. RISC-V Encoding & MemType RISC-V Description ---------- ------------------------------------------------ 00 - PMA Normal Cacheable, No change to implied PMA memory type 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory 11 - Rsvd Reserved for future standard use The standard protection_map[] needn't be modified because the "PMA" type keeps the highest bits zero. And the whole modification is limited in the arch/riscv/* and using a global variable (__svpbmt) as _PAGE_MASK/IO/NOCACHE for pgprot_noncached (&writecombine) in pgtable.h. We also add _PAGE_CHG_MASK to filter PFN than before. Enable it in devicetree - (Add "riscv,svpbmt" in the mmu of cpu node) - mmu: riscv,svpmbt Signed-off-by: Wei Fu <wefu@redhat.com> Co-developed-by: Liu Shaohua <liush@allwinnertech.com> Signed-off-by: Liu Shaohua <liush@allwinnertech.com> Co-developed-by: Guo Ren <guoren@kernel.org> Signed-off-by: Guo Ren <guoren@kernel.org> Cc: Palmer Dabbelt <palmerdabbelt@google.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Anup Patel <anup.patel@wdc.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Atish Patra <atish.patra@wdc.com> Cc: Drew Fustini <drew@beagleboard.org> Cc: Wei Fu <wefu@redhat.com> Cc: Wei Wu <lazyparser@gmail.com> Cc: Chen-Yu Tsai <wens@csie.org> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Daniel Lustig <dlustig@nvidia.com> Cc: Greg Favor <gfavor@ventanamicro.com> Cc: Andrea Mondelli <andrea.mondelli@huawei.com> Cc: Jonathan Behrens <behrensj@mit.edu> Cc: Xinhaoqu (Freddie) <xinhaoqu@huawei.com> Cc: Bill Huffman <huffman@cadence.com> Cc: Nick Kossifidis <mick@ics.forth.gr> Cc: Allen Baum <allen.baum@esperantotech.com> Cc: Josh Scheid <jscheid@ventanamicro.com> Cc: Richard Trauben <rtrauben@gmail.com> --- arch/riscv/include/asm/fixmap.h | 2 +- arch/riscv/include/asm/pgtable-64.h | 21 ++++++++++++--- arch/riscv/include/asm/pgtable-bits.h | 39 +++++++++++++++++++++++++-- arch/riscv/include/asm/pgtable.h | 39 ++++++++++++++++++++------- arch/riscv/kernel/cpufeature.c | 35 ++++++++++++++++++++++++ arch/riscv/mm/init.c | 5 ++++ 6 files changed, 126 insertions(+), 15 deletions(-) diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h index 54cbf07fb4e9..5acd99d08e74 100644 --- a/arch/riscv/include/asm/fixmap.h +++ b/arch/riscv/include/asm/fixmap.h @@ -43,7 +43,7 @@ enum fixed_addresses { __end_of_fixed_addresses }; -#define FIXMAP_PAGE_IO PAGE_KERNEL +#define FIXMAP_PAGE_IO PAGE_IOREMAP #define __early_set_fixmap __set_fixmap diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h index 228261aa9628..16d251282b1d 100644 --- a/arch/riscv/include/asm/pgtable-64.h +++ b/arch/riscv/include/asm/pgtable-64.h @@ -59,14 +59,29 @@ static inline void pud_clear(pud_t *pudp) set_pud(pudp, __pud(0)); } +static inline unsigned long _chg_of_pmd(pmd_t pmd) +{ + return (pmd_val(pmd) & _PAGE_CHG_MASK); +} + +static inline unsigned long _chg_of_pud(pud_t pud) +{ + return (pud_val(pud) & _PAGE_CHG_MASK); +} + +static inline unsigned long _chg_of_pte(pte_t pte) +{ + return (pte_val(pte) & _PAGE_CHG_MASK); +} + static inline pmd_t *pud_pgtable(pud_t pud) { - return (pmd_t *)pfn_to_virt(pud_val(pud) >> _PAGE_PFN_SHIFT); + return (pmd_t *)pfn_to_virt(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT); } static inline struct page *pud_page(pud_t pud) { - return pfn_to_page(pud_val(pud) >> _PAGE_PFN_SHIFT); + return pfn_to_page(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT); } static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot) @@ -76,7 +91,7 @@ static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot) static inline unsigned long _pmd_pfn(pmd_t pmd) { - return pmd_val(pmd) >> _PAGE_PFN_SHIFT; + return _chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT; } #define mk_pmd(page, prot) pfn_pmd(page_to_pfn(page), prot) diff --git a/arch/riscv/include/asm/pgtable-bits.h b/arch/riscv/include/asm/pgtable-bits.h index 2ee413912926..e5b0fce4ddc5 100644 --- a/arch/riscv/include/asm/pgtable-bits.h +++ b/arch/riscv/include/asm/pgtable-bits.h @@ -7,7 +7,7 @@ #define _ASM_RISCV_PGTABLE_BITS_H /* - * PTE format: + * rv32 PTE format: * | XLEN-1 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 * PFN reserved for SW D A G U X W R V */ @@ -24,6 +24,40 @@ #define _PAGE_DIRTY (1 << 7) /* Set by hardware on any write */ #define _PAGE_SOFT (1 << 8) /* Reserved for software */ +#if !defined(__ASSEMBLY__) && defined(CONFIG_64BIT) +/* + * rv64 PTE format: + * | 63 | 62 61 | 60 54 | 53 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 + * N MT RSV PFN reserved for SW D A G U X W R V + * [62:61] Memory Type definitions: + * 00 - PMA Normal Cacheable, No change to implied PMA memory type + * 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory + * 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory + * 11 - Rsvd Reserved for future standard use + */ +#define _SVPBMT_PMA 0UL +#define _SVPBMT_NC (1UL << 61) +#define _SVPBMT_IO (1UL << 62) +#define _SVPBMT_MASK (_SVPBMT_NC | _SVPBMT_IO) + +extern struct __svpbmt_struct { + unsigned long mask; + unsigned long pma; + unsigned long nocache; + unsigned long io; +} __svpbmt __cacheline_aligned; + +#define _PAGE_MASK __svpbmt.mask +#define _PAGE_PMA __svpbmt.pma +#define _PAGE_NOCACHE __svpbmt.nocache +#define _PAGE_IO __svpbmt.io +#else +#define _PAGE_MASK 0 +#define _PAGE_PMA 0 +#define _PAGE_NOCACHE 0 +#define _PAGE_IO 0 +#endif /* !__ASSEMBLY__ && CONFIG_64BIT */ + #define _PAGE_SPECIAL _PAGE_SOFT #define _PAGE_TABLE _PAGE_PRESENT @@ -38,7 +72,8 @@ /* Set of bits to preserve across pte_modify() */ #define _PAGE_CHG_MASK (~(unsigned long)(_PAGE_PRESENT | _PAGE_READ | \ _PAGE_WRITE | _PAGE_EXEC | \ - _PAGE_USER | _PAGE_GLOBAL)) + _PAGE_USER | _PAGE_GLOBAL | \ + _PAGE_MASK)) /* * when all of R/W/X are zero, the PTE is a pointer to the next level * of the page table; otherwise, it is a leaf PTE. diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h index bf204e7c1f74..0f7a6541015f 100644 --- a/arch/riscv/include/asm/pgtable.h +++ b/arch/riscv/include/asm/pgtable.h @@ -138,7 +138,8 @@ | _PAGE_PRESENT \ | _PAGE_ACCESSED \ | _PAGE_DIRTY \ - | _PAGE_GLOBAL) + | _PAGE_GLOBAL \ + | _PAGE_PMA) #define PAGE_KERNEL __pgprot(_PAGE_KERNEL) #define PAGE_KERNEL_READ __pgprot(_PAGE_KERNEL & ~_PAGE_WRITE) @@ -148,11 +149,9 @@ #define PAGE_TABLE __pgprot(_PAGE_TABLE) -/* - * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't - * change the properties of memory regions. - */ -#define _PAGE_IOREMAP _PAGE_KERNEL +#define _PAGE_IOREMAP ((_PAGE_KERNEL & ~_PAGE_MASK) | _PAGE_IO) + +#define PAGE_IOREMAP __pgprot(_PAGE_IOREMAP) extern pgd_t swapper_pg_dir[]; @@ -232,12 +231,12 @@ static inline unsigned long _pgd_pfn(pgd_t pgd) static inline struct page *pmd_page(pmd_t pmd) { - return pfn_to_page(pmd_val(pmd) >> _PAGE_PFN_SHIFT); + return pfn_to_page(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT); } static inline unsigned long pmd_page_vaddr(pmd_t pmd) { - return (unsigned long)pfn_to_virt(pmd_val(pmd) >> _PAGE_PFN_SHIFT); + return (unsigned long)pfn_to_virt(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT); } static inline pte_t pmd_pte(pmd_t pmd) @@ -253,7 +252,7 @@ static inline pte_t pud_pte(pud_t pud) /* Yields the page frame number (PFN) of a page table entry */ static inline unsigned long pte_pfn(pte_t pte) { - return (pte_val(pte) >> _PAGE_PFN_SHIFT); + return (_chg_of_pte(pte) >> _PAGE_PFN_SHIFT); } #define pte_page(x) pfn_to_page(pte_pfn(x)) @@ -492,6 +491,28 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma, return ptep_test_and_clear_young(vma, address, ptep); } +#define pgprot_noncached pgprot_noncached +static inline pgprot_t pgprot_noncached(pgprot_t _prot) +{ + unsigned long prot = pgprot_val(_prot); + + prot &= ~_PAGE_MASK; + prot |= _PAGE_IO; + + return __pgprot(prot); +} + +#define pgprot_writecombine pgprot_writecombine +static inline pgprot_t pgprot_writecombine(pgprot_t _prot) +{ + unsigned long prot = pgprot_val(_prot); + + prot &= ~_PAGE_MASK; + prot |= _PAGE_NOCACHE; + + return __pgprot(prot); +} + /* * THP functions */ diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c index d959d207a40d..fa7480cb8b87 100644 --- a/arch/riscv/kernel/cpufeature.c +++ b/arch/riscv/kernel/cpufeature.c @@ -8,6 +8,7 @@ #include <linux/bitmap.h> #include <linux/of.h> +#include <linux/pgtable.h> #include <asm/processor.h> #include <asm/hwcap.h> #include <asm/smp.h> @@ -59,6 +60,38 @@ bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit) } EXPORT_SYMBOL_GPL(__riscv_isa_extension_available); +static void __init mmu_supports_svpbmt(void) +{ +#if defined(CONFIG_MMU) && defined(CONFIG_64BIT) + struct device_node *node; + const char *str; + + for_each_of_cpu_node(node) { + if (of_property_read_string(node, "mmu-type", &str)) + continue; + + if (!strncmp(str + 6, "none", 4)) + continue; + + if (of_property_read_string(node, "mmu", &str)) + continue; + + if (strncmp(str + 6, "svpmbt", 6)) + continue; + } + + __svpbmt.pma = _SVPBMT_PMA; + __svpbmt.nocache = _SVPBMT_NC; + __svpbmt.io = _SVPBMT_IO; + __svpbmt.mask = _SVPBMT_MASK; +#endif +} + +static void __init mmu_supports(void) +{ + mmu_supports_svpbmt(); +} + void __init riscv_fill_hwcap(void) { struct device_node *node; @@ -67,6 +100,8 @@ void __init riscv_fill_hwcap(void) size_t i, j, isa_len; static unsigned long isa2hwcap[256] = {0}; + mmu_supports(); + isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I; isa2hwcap['m'] = isa2hwcap['M'] = COMPAT_HWCAP_ISA_M; isa2hwcap['a'] = isa2hwcap['A'] = COMPAT_HWCAP_ISA_A; diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index 24b2b8044602..e4e658165ee1 100644 --- a/arch/riscv/mm/init.c +++ b/arch/riscv/mm/init.c @@ -854,3 +854,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, return vmemmap_populate_basepages(start, end, node, NULL); } #endif + +#if defined(CONFIG_64BIT) +struct __svpbmt_struct __svpbmt __ro_after_init; +EXPORT_SYMBOL(__svpbmt); +#endif -- 2.25.4 ^ permalink raw reply related [flat|nested] 35+ messages in thread
* Re: [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports 2021-11-29 1:40 ` [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports wefu @ 2021-11-29 10:48 ` Alexandre Ghiti 2021-11-29 13:36 ` Jisheng Zhang ` (2 subsequent siblings) 3 siblings, 0 replies; 35+ messages in thread From: Alexandre Ghiti @ 2021-11-29 10:48 UTC (permalink / raw) To: wefu Cc: anup.patel, atishp04, palmer, guoren, christoph.muellner, philipp.tomsich, hch, liush, lazyparser, drew, linux-riscv, linux-kernel, taiten.peng, aniket.ponkshe, heinrich.schuchardt, gordan.markus, guoren, arnd, wens, maxime, dlustig, gfavor, andrea.mondelli, behrensj, xinhaoqu, huffman, mick, allen.baum, jscheid, rtrauben, Palmer Dabbelt, Atish Patra On Mon, Nov 29, 2021 at 2:42 AM <wefu@redhat.com> wrote: > > From: Wei Fu <wefu@redhat.com> > > This patch follows the standard pure RISC-V Svpbmt extension in > privilege spec to solve the non-coherent SOC dma synchronization > issues. > > Here is the svpbmt PTE format: > | 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > N MT RSW D A G U X W R V > ^ > > Of the Reserved bits [63:54] in a leaf PTE, the high bit is already > allocated (as the N bit), so bits [62:61] are used as the MT (aka > MemType) field. This field specifies one of three memory types that > are close equivalents (or equivalent in effect) to the three main x86 > and ARMv8 memory types - as shown in the following table. > > RISC-V > Encoding & > MemType RISC-V Description > ---------- ------------------------------------------------ > 00 - PMA Normal Cacheable, No change to implied PMA memory type > 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory > 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory > 11 - Rsvd Reserved for future standard use > > The standard protection_map[] needn't be modified because the "PMA" > type keeps the highest bits zero. And the whole modification is > limited in the arch/riscv/* and using a global variable > (__svpbmt) as _PAGE_MASK/IO/NOCACHE for pgprot_noncached > (&writecombine) in pgtable.h. We also add _PAGE_CHG_MASK to filter > PFN than before. > > Enable it in devicetree - (Add "riscv,svpbmt" in the mmu of cpu node) > - mmu: > riscv,svpmbt > > Signed-off-by: Wei Fu <wefu@redhat.com> > Co-developed-by: Liu Shaohua <liush@allwinnertech.com> > Signed-off-by: Liu Shaohua <liush@allwinnertech.com> > Co-developed-by: Guo Ren <guoren@kernel.org> > Signed-off-by: Guo Ren <guoren@kernel.org> > Cc: Palmer Dabbelt <palmerdabbelt@google.com> > Cc: Christoph Hellwig <hch@lst.de> > Cc: Anup Patel <anup.patel@wdc.com> > Cc: Arnd Bergmann <arnd@arndb.de> > Cc: Atish Patra <atish.patra@wdc.com> > Cc: Drew Fustini <drew@beagleboard.org> > Cc: Wei Fu <wefu@redhat.com> > Cc: Wei Wu <lazyparser@gmail.com> > Cc: Chen-Yu Tsai <wens@csie.org> > Cc: Maxime Ripard <maxime@cerno.tech> > Cc: Daniel Lustig <dlustig@nvidia.com> > Cc: Greg Favor <gfavor@ventanamicro.com> > Cc: Andrea Mondelli <andrea.mondelli@huawei.com> > Cc: Jonathan Behrens <behrensj@mit.edu> > Cc: Xinhaoqu (Freddie) <xinhaoqu@huawei.com> > Cc: Bill Huffman <huffman@cadence.com> > Cc: Nick Kossifidis <mick@ics.forth.gr> > Cc: Allen Baum <allen.baum@esperantotech.com> > Cc: Josh Scheid <jscheid@ventanamicro.com> > Cc: Richard Trauben <rtrauben@gmail.com> > --- > arch/riscv/include/asm/fixmap.h | 2 +- > arch/riscv/include/asm/pgtable-64.h | 21 ++++++++++++--- > arch/riscv/include/asm/pgtable-bits.h | 39 +++++++++++++++++++++++++-- > arch/riscv/include/asm/pgtable.h | 39 ++++++++++++++++++++------- > arch/riscv/kernel/cpufeature.c | 35 ++++++++++++++++++++++++ > arch/riscv/mm/init.c | 5 ++++ > 6 files changed, 126 insertions(+), 15 deletions(-) > > diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h > index 54cbf07fb4e9..5acd99d08e74 100644 > --- a/arch/riscv/include/asm/fixmap.h > +++ b/arch/riscv/include/asm/fixmap.h > @@ -43,7 +43,7 @@ enum fixed_addresses { > __end_of_fixed_addresses > }; > > -#define FIXMAP_PAGE_IO PAGE_KERNEL > +#define FIXMAP_PAGE_IO PAGE_IOREMAP > > #define __early_set_fixmap __set_fixmap > > diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h > index 228261aa9628..16d251282b1d 100644 > --- a/arch/riscv/include/asm/pgtable-64.h > +++ b/arch/riscv/include/asm/pgtable-64.h > @@ -59,14 +59,29 @@ static inline void pud_clear(pud_t *pudp) > set_pud(pudp, __pud(0)); > } > > +static inline unsigned long _chg_of_pmd(pmd_t pmd) > +{ > + return (pmd_val(pmd) & _PAGE_CHG_MASK); > +} > + > +static inline unsigned long _chg_of_pud(pud_t pud) > +{ > + return (pud_val(pud) & _PAGE_CHG_MASK); > +} > + > +static inline unsigned long _chg_of_pte(pte_t pte) > +{ > + return (pte_val(pte) & _PAGE_CHG_MASK); > +} Those functions are used to extract the pfn from a page table entry, IMO it would be clearer if those functions would look like that: static inline unsigned long pmd_to_pfn(pmd_t pmd) { return (pmd_val(pmd) & _PAGE_CHG_MASK) >> _PAGE_PFN_SHIFT; } > + > static inline pmd_t *pud_pgtable(pud_t pud) > { > - return (pmd_t *)pfn_to_virt(pud_val(pud) >> _PAGE_PFN_SHIFT); > + return (pmd_t *)pfn_to_virt(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT); > } > > static inline struct page *pud_page(pud_t pud) > { > - return pfn_to_page(pud_val(pud) >> _PAGE_PFN_SHIFT); > + return pfn_to_page(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT); > } > > static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot) > @@ -76,7 +91,7 @@ static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot) > > static inline unsigned long _pmd_pfn(pmd_t pmd) > { > - return pmd_val(pmd) >> _PAGE_PFN_SHIFT; > + return _chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT; > } > Like this one actually, so if this exists for other levels, I would suggest to modify those functions to directly mask the PMA bits and use those in the whole code instead of manually extracting the pfn. > #define mk_pmd(page, prot) pfn_pmd(page_to_pfn(page), prot) > diff --git a/arch/riscv/include/asm/pgtable-bits.h b/arch/riscv/include/asm/pgtable-bits.h > index 2ee413912926..e5b0fce4ddc5 100644 > --- a/arch/riscv/include/asm/pgtable-bits.h > +++ b/arch/riscv/include/asm/pgtable-bits.h > @@ -7,7 +7,7 @@ > #define _ASM_RISCV_PGTABLE_BITS_H > > /* > - * PTE format: > + * rv32 PTE format: > * | XLEN-1 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > * PFN reserved for SW D A G U X W R V > */ > @@ -24,6 +24,40 @@ > #define _PAGE_DIRTY (1 << 7) /* Set by hardware on any write */ > #define _PAGE_SOFT (1 << 8) /* Reserved for software */ > > +#if !defined(__ASSEMBLY__) && defined(CONFIG_64BIT) > +/* > + * rv64 PTE format: > + * | 63 | 62 61 | 60 54 | 53 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > + * N MT RSV PFN reserved for SW D A G U X W R V > + * [62:61] Memory Type definitions: > + * 00 - PMA Normal Cacheable, No change to implied PMA memory type > + * 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory > + * 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory > + * 11 - Rsvd Reserved for future standard use > + */ > +#define _SVPBMT_PMA 0UL > +#define _SVPBMT_NC (1UL << 61) > +#define _SVPBMT_IO (1UL << 62) > +#define _SVPBMT_MASK (_SVPBMT_NC | _SVPBMT_IO) > + > +extern struct __svpbmt_struct { > + unsigned long mask; > + unsigned long pma; > + unsigned long nocache; > + unsigned long io; > +} __svpbmt __cacheline_aligned; > + > +#define _PAGE_MASK __svpbmt.mask To me, _PAGE_MASK means something else: https://elixir.bootlin.com/linux/latest/source/arch/s390/include/asm/page.h#L16 Maybe something more explicit like _PAGE_SVPBMT_MASK? > +#define _PAGE_PMA __svpbmt.pma > +#define _PAGE_NOCACHE __svpbmt.nocache > +#define _PAGE_IO __svpbmt.io > +#else > +#define _PAGE_MASK 0 > +#define _PAGE_PMA 0 > +#define _PAGE_NOCACHE 0 > +#define _PAGE_IO 0 > +#endif /* !__ASSEMBLY__ && CONFIG_64BIT */ > + > #define _PAGE_SPECIAL _PAGE_SOFT > #define _PAGE_TABLE _PAGE_PRESENT > > @@ -38,7 +72,8 @@ > /* Set of bits to preserve across pte_modify() */ > #define _PAGE_CHG_MASK (~(unsigned long)(_PAGE_PRESENT | _PAGE_READ | \ > _PAGE_WRITE | _PAGE_EXEC | \ > - _PAGE_USER | _PAGE_GLOBAL)) > + _PAGE_USER | _PAGE_GLOBAL | \ > + _PAGE_MASK)) > /* > * when all of R/W/X are zero, the PTE is a pointer to the next level > * of the page table; otherwise, it is a leaf PTE. > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h > index bf204e7c1f74..0f7a6541015f 100644 > --- a/arch/riscv/include/asm/pgtable.h > +++ b/arch/riscv/include/asm/pgtable.h > @@ -138,7 +138,8 @@ > | _PAGE_PRESENT \ > | _PAGE_ACCESSED \ > | _PAGE_DIRTY \ > - | _PAGE_GLOBAL) > + | _PAGE_GLOBAL \ > + | _PAGE_PMA) > > #define PAGE_KERNEL __pgprot(_PAGE_KERNEL) > #define PAGE_KERNEL_READ __pgprot(_PAGE_KERNEL & ~_PAGE_WRITE) > @@ -148,11 +149,9 @@ > > #define PAGE_TABLE __pgprot(_PAGE_TABLE) > > -/* > - * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't > - * change the properties of memory regions. > - */ > -#define _PAGE_IOREMAP _PAGE_KERNEL > +#define _PAGE_IOREMAP ((_PAGE_KERNEL & ~_PAGE_MASK) | _PAGE_IO) > + > +#define PAGE_IOREMAP __pgprot(_PAGE_IOREMAP) > > extern pgd_t swapper_pg_dir[]; > > @@ -232,12 +231,12 @@ static inline unsigned long _pgd_pfn(pgd_t pgd) > > static inline struct page *pmd_page(pmd_t pmd) > { > - return pfn_to_page(pmd_val(pmd) >> _PAGE_PFN_SHIFT); > + return pfn_to_page(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT); > } > > static inline unsigned long pmd_page_vaddr(pmd_t pmd) > { > - return (unsigned long)pfn_to_virt(pmd_val(pmd) >> _PAGE_PFN_SHIFT); > + return (unsigned long)pfn_to_virt(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT); > } > > static inline pte_t pmd_pte(pmd_t pmd) > @@ -253,7 +252,7 @@ static inline pte_t pud_pte(pud_t pud) > /* Yields the page frame number (PFN) of a page table entry */ > static inline unsigned long pte_pfn(pte_t pte) > { > - return (pte_val(pte) >> _PAGE_PFN_SHIFT); > + return (_chg_of_pte(pte) >> _PAGE_PFN_SHIFT); > } > > #define pte_page(x) pfn_to_page(pte_pfn(x)) > @@ -492,6 +491,28 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma, > return ptep_test_and_clear_young(vma, address, ptep); > } > > +#define pgprot_noncached pgprot_noncached > +static inline pgprot_t pgprot_noncached(pgprot_t _prot) > +{ > + unsigned long prot = pgprot_val(_prot); > + > + prot &= ~_PAGE_MASK; > + prot |= _PAGE_IO; > + > + return __pgprot(prot); > +} > + > +#define pgprot_writecombine pgprot_writecombine > +static inline pgprot_t pgprot_writecombine(pgprot_t _prot) > +{ > + unsigned long prot = pgprot_val(_prot); > + > + prot &= ~_PAGE_MASK; > + prot |= _PAGE_NOCACHE; > + > + return __pgprot(prot); > +} > + > /* > * THP functions > */ > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c > index d959d207a40d..fa7480cb8b87 100644 > --- a/arch/riscv/kernel/cpufeature.c > +++ b/arch/riscv/kernel/cpufeature.c > @@ -8,6 +8,7 @@ > > #include <linux/bitmap.h> > #include <linux/of.h> > +#include <linux/pgtable.h> > #include <asm/processor.h> > #include <asm/hwcap.h> > #include <asm/smp.h> > @@ -59,6 +60,38 @@ bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit) > } > EXPORT_SYMBOL_GPL(__riscv_isa_extension_available); > > +static void __init mmu_supports_svpbmt(void) > +{ > +#if defined(CONFIG_MMU) && defined(CONFIG_64BIT) > + struct device_node *node; > + const char *str; > + > + for_each_of_cpu_node(node) { > + if (of_property_read_string(node, "mmu-type", &str)) > + continue; > + > + if (!strncmp(str + 6, "none", 4)) > + continue; > + > + if (of_property_read_string(node, "mmu", &str)) > + continue; > + > + if (strncmp(str + 6, "svpmbt", 6)) > + continue; > + } > + > + __svpbmt.pma = _SVPBMT_PMA; > + __svpbmt.nocache = _SVPBMT_NC; > + __svpbmt.io = _SVPBMT_IO; > + __svpbmt.mask = _SVPBMT_MASK; > +#endif > +} > + > +static void __init mmu_supports(void) > +{ > + mmu_supports_svpbmt(); > +} > + > void __init riscv_fill_hwcap(void) > { > struct device_node *node; > @@ -67,6 +100,8 @@ void __init riscv_fill_hwcap(void) > size_t i, j, isa_len; > static unsigned long isa2hwcap[256] = {0}; > > + mmu_supports(); > + > isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I; > isa2hwcap['m'] = isa2hwcap['M'] = COMPAT_HWCAP_ISA_M; > isa2hwcap['a'] = isa2hwcap['A'] = COMPAT_HWCAP_ISA_A; > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c > index 24b2b8044602..e4e658165ee1 100644 > --- a/arch/riscv/mm/init.c > +++ b/arch/riscv/mm/init.c > @@ -854,3 +854,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, > return vmemmap_populate_basepages(start, end, node, NULL); > } > #endif > + > +#if defined(CONFIG_64BIT) > +struct __svpbmt_struct __svpbmt __ro_after_init; > +EXPORT_SYMBOL(__svpbmt); > +#endif > -- > 2.25.4 > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports 2021-11-29 1:40 ` [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports wefu 2021-11-29 10:48 ` Alexandre Ghiti @ 2021-11-29 13:36 ` Jisheng Zhang 2021-12-01 5:05 ` Wei Fu 2021-11-30 10:18 ` Guo Ren 2021-11-30 18:46 ` Heiko Stübner 3 siblings, 1 reply; 35+ messages in thread From: Jisheng Zhang @ 2021-11-29 13:36 UTC (permalink / raw) To: wefu Cc: anup.patel, atishp04, palmer, guoren, christoph.muellner, philipp.tomsich, hch, liush, lazyparser, drew, linux-riscv, linux-kernel, taiten.peng, aniket.ponkshe, heinrich.schuchardt, gordan.markus, guoren, arnd, wens, maxime, dlustig, gfavor, andrea.mondelli, behrensj, xinhaoqu, huffman, mick, allen.baum, jscheid, rtrauben, Palmer Dabbelt, Atish Patra On Mon, 29 Nov 2021 09:40:07 +0800 wefu@redhat.com wrote: > From: Wei Fu <wefu@redhat.com> > > This patch follows the standard pure RISC-V Svpbmt extension in > privilege spec to solve the non-coherent SOC dma synchronization > issues. > > Here is the svpbmt PTE format: > | 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > N MT RSW D A G U X W R V > ^ > > Of the Reserved bits [63:54] in a leaf PTE, the high bit is already > allocated (as the N bit), so bits [62:61] are used as the MT (aka > MemType) field. This field specifies one of three memory types that > are close equivalents (or equivalent in effect) to the three main x86 > and ARMv8 memory types - as shown in the following table. > > RISC-V > Encoding & > MemType RISC-V Description > ---------- ------------------------------------------------ > 00 - PMA Normal Cacheable, No change to implied PMA memory type > 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory > 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory > 11 - Rsvd Reserved for future standard use > > The standard protection_map[] needn't be modified because the "PMA" > type keeps the highest bits zero. And the whole modification is > limited in the arch/riscv/* and using a global variable > (__svpbmt) as _PAGE_MASK/IO/NOCACHE for pgprot_noncached > (&writecombine) in pgtable.h. We also add _PAGE_CHG_MASK to filter > PFN than before. > > Enable it in devicetree - (Add "riscv,svpbmt" in the mmu of cpu node) > - mmu: > riscv,svpmbt > > Signed-off-by: Wei Fu <wefu@redhat.com> > Co-developed-by: Liu Shaohua <liush@allwinnertech.com> > Signed-off-by: Liu Shaohua <liush@allwinnertech.com> > Co-developed-by: Guo Ren <guoren@kernel.org> > Signed-off-by: Guo Ren <guoren@kernel.org> > Cc: Palmer Dabbelt <palmerdabbelt@google.com> > Cc: Christoph Hellwig <hch@lst.de> > Cc: Anup Patel <anup.patel@wdc.com> > Cc: Arnd Bergmann <arnd@arndb.de> > Cc: Atish Patra <atish.patra@wdc.com> > Cc: Drew Fustini <drew@beagleboard.org> > Cc: Wei Fu <wefu@redhat.com> > Cc: Wei Wu <lazyparser@gmail.com> > Cc: Chen-Yu Tsai <wens@csie.org> > Cc: Maxime Ripard <maxime@cerno.tech> > Cc: Daniel Lustig <dlustig@nvidia.com> > Cc: Greg Favor <gfavor@ventanamicro.com> > Cc: Andrea Mondelli <andrea.mondelli@huawei.com> > Cc: Jonathan Behrens <behrensj@mit.edu> > Cc: Xinhaoqu (Freddie) <xinhaoqu@huawei.com> > Cc: Bill Huffman <huffman@cadence.com> > Cc: Nick Kossifidis <mick@ics.forth.gr> > Cc: Allen Baum <allen.baum@esperantotech.com> > Cc: Josh Scheid <jscheid@ventanamicro.com> > Cc: Richard Trauben <rtrauben@gmail.com> > --- > arch/riscv/include/asm/fixmap.h | 2 +- > arch/riscv/include/asm/pgtable-64.h | 21 ++++++++++++--- > arch/riscv/include/asm/pgtable-bits.h | 39 +++++++++++++++++++++++++-- > arch/riscv/include/asm/pgtable.h | 39 ++++++++++++++++++++------- > arch/riscv/kernel/cpufeature.c | 35 ++++++++++++++++++++++++ > arch/riscv/mm/init.c | 5 ++++ > 6 files changed, 126 insertions(+), 15 deletions(-) > > diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h > index 54cbf07fb4e9..5acd99d08e74 100644 > --- a/arch/riscv/include/asm/fixmap.h > +++ b/arch/riscv/include/asm/fixmap.h > @@ -43,7 +43,7 @@ enum fixed_addresses { > __end_of_fixed_addresses > }; > > -#define FIXMAP_PAGE_IO PAGE_KERNEL > +#define FIXMAP_PAGE_IO PAGE_IOREMAP > > #define __early_set_fixmap __set_fixmap > > diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h > index 228261aa9628..16d251282b1d 100644 > --- a/arch/riscv/include/asm/pgtable-64.h > +++ b/arch/riscv/include/asm/pgtable-64.h > @@ -59,14 +59,29 @@ static inline void pud_clear(pud_t *pudp) > set_pud(pudp, __pud(0)); > } > > +static inline unsigned long _chg_of_pmd(pmd_t pmd) > +{ > + return (pmd_val(pmd) & _PAGE_CHG_MASK); > +} > + > +static inline unsigned long _chg_of_pud(pud_t pud) > +{ > + return (pud_val(pud) & _PAGE_CHG_MASK); > +} > + > +static inline unsigned long _chg_of_pte(pte_t pte) > +{ > + return (pte_val(pte) & _PAGE_CHG_MASK); > +} > + > static inline pmd_t *pud_pgtable(pud_t pud) > { > - return (pmd_t *)pfn_to_virt(pud_val(pud) >> _PAGE_PFN_SHIFT); > + return (pmd_t *)pfn_to_virt(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT); > } > > static inline struct page *pud_page(pud_t pud) > { > - return pfn_to_page(pud_val(pud) >> _PAGE_PFN_SHIFT); > + return pfn_to_page(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT); > } > > static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot) > @@ -76,7 +91,7 @@ static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot) > > static inline unsigned long _pmd_pfn(pmd_t pmd) > { > - return pmd_val(pmd) >> _PAGE_PFN_SHIFT; > + return _chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT; > } > > #define mk_pmd(page, prot) pfn_pmd(page_to_pfn(page), prot) > diff --git a/arch/riscv/include/asm/pgtable-bits.h b/arch/riscv/include/asm/pgtable-bits.h > index 2ee413912926..e5b0fce4ddc5 100644 > --- a/arch/riscv/include/asm/pgtable-bits.h > +++ b/arch/riscv/include/asm/pgtable-bits.h > @@ -7,7 +7,7 @@ > #define _ASM_RISCV_PGTABLE_BITS_H > > /* > - * PTE format: > + * rv32 PTE format: > * | XLEN-1 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > * PFN reserved for SW D A G U X W R V > */ > @@ -24,6 +24,40 @@ > #define _PAGE_DIRTY (1 << 7) /* Set by hardware on any write */ > #define _PAGE_SOFT (1 << 8) /* Reserved for software */ > > +#if !defined(__ASSEMBLY__) && defined(CONFIG_64BIT) > +/* > + * rv64 PTE format: > + * | 63 | 62 61 | 60 54 | 53 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > + * N MT RSV PFN reserved for SW D A G U X W R V > + * [62:61] Memory Type definitions: > + * 00 - PMA Normal Cacheable, No change to implied PMA memory type > + * 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory > + * 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory > + * 11 - Rsvd Reserved for future standard use > + */ > +#define _SVPBMT_PMA 0UL > +#define _SVPBMT_NC (1UL << 61) > +#define _SVPBMT_IO (1UL << 62) > +#define _SVPBMT_MASK (_SVPBMT_NC | _SVPBMT_IO) > + > +extern struct __svpbmt_struct { > + unsigned long mask; > + unsigned long pma; > + unsigned long nocache; > + unsigned long io; > +} __svpbmt __cacheline_aligned; > + > +#define _PAGE_MASK __svpbmt.mask > +#define _PAGE_PMA __svpbmt.pma > +#define _PAGE_NOCACHE __svpbmt.nocache > +#define _PAGE_IO __svpbmt.io > +#else > +#define _PAGE_MASK 0 > +#define _PAGE_PMA 0 > +#define _PAGE_NOCACHE 0 > +#define _PAGE_IO 0 > +#endif /* !__ASSEMBLY__ && CONFIG_64BIT */ > + > #define _PAGE_SPECIAL _PAGE_SOFT > #define _PAGE_TABLE _PAGE_PRESENT > > @@ -38,7 +72,8 @@ > /* Set of bits to preserve across pte_modify() */ > #define _PAGE_CHG_MASK (~(unsigned long)(_PAGE_PRESENT | _PAGE_READ | \ > _PAGE_WRITE | _PAGE_EXEC | \ > - _PAGE_USER | _PAGE_GLOBAL)) > + _PAGE_USER | _PAGE_GLOBAL | \ > + _PAGE_MASK)) > /* > * when all of R/W/X are zero, the PTE is a pointer to the next level > * of the page table; otherwise, it is a leaf PTE. > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h > index bf204e7c1f74..0f7a6541015f 100644 > --- a/arch/riscv/include/asm/pgtable.h > +++ b/arch/riscv/include/asm/pgtable.h > @@ -138,7 +138,8 @@ > | _PAGE_PRESENT \ > | _PAGE_ACCESSED \ > | _PAGE_DIRTY \ > - | _PAGE_GLOBAL) > + | _PAGE_GLOBAL \ > + | _PAGE_PMA) > > #define PAGE_KERNEL __pgprot(_PAGE_KERNEL) > #define PAGE_KERNEL_READ __pgprot(_PAGE_KERNEL & ~_PAGE_WRITE) > @@ -148,11 +149,9 @@ > > #define PAGE_TABLE __pgprot(_PAGE_TABLE) > > -/* > - * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't > - * change the properties of memory regions. > - */ > -#define _PAGE_IOREMAP _PAGE_KERNEL > +#define _PAGE_IOREMAP ((_PAGE_KERNEL & ~_PAGE_MASK) | _PAGE_IO) > + > +#define PAGE_IOREMAP __pgprot(_PAGE_IOREMAP) > > extern pgd_t swapper_pg_dir[]; > > @@ -232,12 +231,12 @@ static inline unsigned long _pgd_pfn(pgd_t pgd) > > static inline struct page *pmd_page(pmd_t pmd) > { > - return pfn_to_page(pmd_val(pmd) >> _PAGE_PFN_SHIFT); > + return pfn_to_page(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT); > } > > static inline unsigned long pmd_page_vaddr(pmd_t pmd) > { > - return (unsigned long)pfn_to_virt(pmd_val(pmd) >> _PAGE_PFN_SHIFT); > + return (unsigned long)pfn_to_virt(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT); > } > > static inline pte_t pmd_pte(pmd_t pmd) > @@ -253,7 +252,7 @@ static inline pte_t pud_pte(pud_t pud) > /* Yields the page frame number (PFN) of a page table entry */ > static inline unsigned long pte_pfn(pte_t pte) > { > - return (pte_val(pte) >> _PAGE_PFN_SHIFT); > + return (_chg_of_pte(pte) >> _PAGE_PFN_SHIFT); > } > > #define pte_page(x) pfn_to_page(pte_pfn(x)) > @@ -492,6 +491,28 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma, > return ptep_test_and_clear_young(vma, address, ptep); > } > > +#define pgprot_noncached pgprot_noncached > +static inline pgprot_t pgprot_noncached(pgprot_t _prot) > +{ > + unsigned long prot = pgprot_val(_prot); > + > + prot &= ~_PAGE_MASK; > + prot |= _PAGE_IO; > + > + return __pgprot(prot); > +} > + > +#define pgprot_writecombine pgprot_writecombine > +static inline pgprot_t pgprot_writecombine(pgprot_t _prot) > +{ > + unsigned long prot = pgprot_val(_prot); > + > + prot &= ~_PAGE_MASK; > + prot |= _PAGE_NOCACHE; > + > + return __pgprot(prot); > +} > + > /* > * THP functions > */ > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c > index d959d207a40d..fa7480cb8b87 100644 > --- a/arch/riscv/kernel/cpufeature.c > +++ b/arch/riscv/kernel/cpufeature.c > @@ -8,6 +8,7 @@ > > #include <linux/bitmap.h> > #include <linux/of.h> > +#include <linux/pgtable.h> > #include <asm/processor.h> > #include <asm/hwcap.h> > #include <asm/smp.h> > @@ -59,6 +60,38 @@ bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit) > } > EXPORT_SYMBOL_GPL(__riscv_isa_extension_available); > > +static void __init mmu_supports_svpbmt(void) > +{ > +#if defined(CONFIG_MMU) && defined(CONFIG_64BIT) IIRC, Christoph suggested a CONFIG_RISCV_SVPBMT when reviewing v3. What about that idea? > + struct device_node *node; > + const char *str; > + > + for_each_of_cpu_node(node) { > + if (of_property_read_string(node, "mmu-type", &str)) > + continue; > + > + if (!strncmp(str + 6, "none", 4)) > + continue; > + > + if (of_property_read_string(node, "mmu", &str)) > + continue; > + > + if (strncmp(str + 6, "svpmbt", 6)) > + continue; > + } > + > + __svpbmt.pma = _SVPBMT_PMA; > + __svpbmt.nocache = _SVPBMT_NC; > + __svpbmt.io = _SVPBMT_IO; > + __svpbmt.mask = _SVPBMT_MASK; > +#endif > +} > + > +static void __init mmu_supports(void) can we remove this function currently? Instead, directly call mmu_supports_svpbmt()? > +{ > + mmu_supports_svpbmt(); > +} > + > void __init riscv_fill_hwcap(void) > { > struct device_node *node; > @@ -67,6 +100,8 @@ void __init riscv_fill_hwcap(void) > size_t i, j, isa_len; > static unsigned long isa2hwcap[256] = {0}; > > + mmu_supports(); > + > isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I; > isa2hwcap['m'] = isa2hwcap['M'] = COMPAT_HWCAP_ISA_M; > isa2hwcap['a'] = isa2hwcap['A'] = COMPAT_HWCAP_ISA_A; > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c > index 24b2b8044602..e4e658165ee1 100644 > --- a/arch/riscv/mm/init.c > +++ b/arch/riscv/mm/init.c > @@ -854,3 +854,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, > return vmemmap_populate_basepages(start, end, node, NULL); > } > #endif > + > +#if defined(CONFIG_64BIT) > +struct __svpbmt_struct __svpbmt __ro_after_init; Added the structure for all RV64 including NOMMU case and those platforms which doen't want SVPBMT at all, I believe Christoph's CONFIG_RISCV_SVPBMT suggestion can solve this problem. > +EXPORT_SYMBOL(__svpbmt); > +#endif ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports 2021-11-29 13:36 ` Jisheng Zhang @ 2021-12-01 5:05 ` Wei Fu 2021-12-01 6:18 ` Anup Patel 0 siblings, 1 reply; 35+ messages in thread From: Wei Fu @ 2021-12-01 5:05 UTC (permalink / raw) To: Jisheng Zhang Cc: Anup Patel, atishp04, Palmer Dabbelt, Guo Ren, Christoph Müllner, Philipp Tomsich, Christoph Hellwig, Liu Shaohua, Wei Wu (吴伟), Drew Fustini, linux-riscv, Linux Kernel Mailing List, taiten.peng, Aniket Ponkshe, Heinrich Schuchardt, Gordan Markus, Guo Ren, Arnd Bergmann, Chen-Yu Tsai, Maxime Ripard, Daniel Lustig, Greg Favor, Andrea Mondelli, Jonathan Behrens, Xinhaoqu, Bill Huffman, Nick Kossifidis, Allen Baum, Josh Scheid, Richard Trauben Hi, Jisheng Zhang, On Mon, Nov 29, 2021 at 9:44 PM Jisheng Zhang <jszhang@kernel.org> wrote: > > On Mon, 29 Nov 2021 09:40:07 +0800 > wefu@redhat.com wrote: > > > From: Wei Fu <wefu@redhat.com> > > > > This patch follows the standard pure RISC-V Svpbmt extension in > > privilege spec to solve the non-coherent SOC dma synchronization > > issues. > > > > Here is the svpbmt PTE format: > > | 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > > N MT RSW D A G U X W R V > > ^ > > > > Of the Reserved bits [63:54] in a leaf PTE, the high bit is already > > allocated (as the N bit), so bits [62:61] are used as the MT (aka > > MemType) field. This field specifies one of three memory types that > > are close equivalents (or equivalent in effect) to the three main x86 > > and ARMv8 memory types - as shown in the following table. > > > > RISC-V > > Encoding & > > MemType RISC-V Description > > ---------- ------------------------------------------------ > > 00 - PMA Normal Cacheable, No change to implied PMA memory type > > 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory > > 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory > > 11 - Rsvd Reserved for future standard use > > > > The standard protection_map[] needn't be modified because the "PMA" > > type keeps the highest bits zero. And the whole modification is > > limited in the arch/riscv/* and using a global variable > > (__svpbmt) as _PAGE_MASK/IO/NOCACHE for pgprot_noncached > > (&writecombine) in pgtable.h. We also add _PAGE_CHG_MASK to filter > > PFN than before. > > > > Enable it in devicetree - (Add "riscv,svpbmt" in the mmu of cpu node) > > - mmu: > > riscv,svpmbt > > > > Signed-off-by: Wei Fu <wefu@redhat.com> > > Co-developed-by: Liu Shaohua <liush@allwinnertech.com> > > Signed-off-by: Liu Shaohua <liush@allwinnertech.com> > > Co-developed-by: Guo Ren <guoren@kernel.org> > > Signed-off-by: Guo Ren <guoren@kernel.org> > > Cc: Palmer Dabbelt <palmerdabbelt@google.com> > > Cc: Christoph Hellwig <hch@lst.de> > > Cc: Anup Patel <anup.patel@wdc.com> > > Cc: Arnd Bergmann <arnd@arndb.de> > > Cc: Atish Patra <atish.patra@wdc.com> > > Cc: Drew Fustini <drew@beagleboard.org> > > Cc: Wei Fu <wefu@redhat.com> > > Cc: Wei Wu <lazyparser@gmail.com> > > Cc: Chen-Yu Tsai <wens@csie.org> > > Cc: Maxime Ripard <maxime@cerno.tech> > > Cc: Daniel Lustig <dlustig@nvidia.com> > > Cc: Greg Favor <gfavor@ventanamicro.com> > > Cc: Andrea Mondelli <andrea.mondelli@huawei.com> > > Cc: Jonathan Behrens <behrensj@mit.edu> > > Cc: Xinhaoqu (Freddie) <xinhaoqu@huawei.com> > > Cc: Bill Huffman <huffman@cadence.com> > > Cc: Nick Kossifidis <mick@ics.forth.gr> > > Cc: Allen Baum <allen.baum@esperantotech.com> > > Cc: Josh Scheid <jscheid@ventanamicro.com> > > Cc: Richard Trauben <rtrauben@gmail.com> > > --- > > arch/riscv/include/asm/fixmap.h | 2 +- > > arch/riscv/include/asm/pgtable-64.h | 21 ++++++++++++--- > > arch/riscv/include/asm/pgtable-bits.h | 39 +++++++++++++++++++++++++-- > > arch/riscv/include/asm/pgtable.h | 39 ++++++++++++++++++++------- > > arch/riscv/kernel/cpufeature.c | 35 ++++++++++++++++++++++++ > > arch/riscv/mm/init.c | 5 ++++ > > 6 files changed, 126 insertions(+), 15 deletions(-) > > > > diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h > > index 54cbf07fb4e9..5acd99d08e74 100644 > > --- a/arch/riscv/include/asm/fixmap.h > > +++ b/arch/riscv/include/asm/fixmap.h > > @@ -43,7 +43,7 @@ enum fixed_addresses { > > __end_of_fixed_addresses > > }; > > > > -#define FIXMAP_PAGE_IO PAGE_KERNEL > > +#define FIXMAP_PAGE_IO PAGE_IOREMAP > > > > #define __early_set_fixmap __set_fixmap > > > > diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h > > index 228261aa9628..16d251282b1d 100644 > > --- a/arch/riscv/include/asm/pgtable-64.h > > +++ b/arch/riscv/include/asm/pgtable-64.h > > @@ -59,14 +59,29 @@ static inline void pud_clear(pud_t *pudp) > > set_pud(pudp, __pud(0)); > > } > > > > +static inline unsigned long _chg_of_pmd(pmd_t pmd) > > +{ > > + return (pmd_val(pmd) & _PAGE_CHG_MASK); > > +} > > + > > +static inline unsigned long _chg_of_pud(pud_t pud) > > +{ > > + return (pud_val(pud) & _PAGE_CHG_MASK); > > +} > > + > > +static inline unsigned long _chg_of_pte(pte_t pte) > > +{ > > + return (pte_val(pte) & _PAGE_CHG_MASK); > > +} > > + > > static inline pmd_t *pud_pgtable(pud_t pud) > > { > > - return (pmd_t *)pfn_to_virt(pud_val(pud) >> _PAGE_PFN_SHIFT); > > + return (pmd_t *)pfn_to_virt(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT); > > } > > > > static inline struct page *pud_page(pud_t pud) > > { > > - return pfn_to_page(pud_val(pud) >> _PAGE_PFN_SHIFT); > > + return pfn_to_page(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT); > > } > > > > static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot) > > @@ -76,7 +91,7 @@ static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot) > > > > static inline unsigned long _pmd_pfn(pmd_t pmd) > > { > > - return pmd_val(pmd) >> _PAGE_PFN_SHIFT; > > + return _chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT; > > } > > > > #define mk_pmd(page, prot) pfn_pmd(page_to_pfn(page), prot) > > diff --git a/arch/riscv/include/asm/pgtable-bits.h b/arch/riscv/include/asm/pgtable-bits.h > > index 2ee413912926..e5b0fce4ddc5 100644 > > --- a/arch/riscv/include/asm/pgtable-bits.h > > +++ b/arch/riscv/include/asm/pgtable-bits.h > > @@ -7,7 +7,7 @@ > > #define _ASM_RISCV_PGTABLE_BITS_H > > > > /* > > - * PTE format: > > + * rv32 PTE format: > > * | XLEN-1 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > > * PFN reserved for SW D A G U X W R V > > */ > > @@ -24,6 +24,40 @@ > > #define _PAGE_DIRTY (1 << 7) /* Set by hardware on any write */ > > #define _PAGE_SOFT (1 << 8) /* Reserved for software */ > > > > +#if !defined(__ASSEMBLY__) && defined(CONFIG_64BIT) > > +/* > > + * rv64 PTE format: > > + * | 63 | 62 61 | 60 54 | 53 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > > + * N MT RSV PFN reserved for SW D A G U X W R V > > + * [62:61] Memory Type definitions: > > + * 00 - PMA Normal Cacheable, No change to implied PMA memory type > > + * 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory > > + * 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory > > + * 11 - Rsvd Reserved for future standard use > > + */ > > +#define _SVPBMT_PMA 0UL > > +#define _SVPBMT_NC (1UL << 61) > > +#define _SVPBMT_IO (1UL << 62) > > +#define _SVPBMT_MASK (_SVPBMT_NC | _SVPBMT_IO) > > + > > +extern struct __svpbmt_struct { > > + unsigned long mask; > > + unsigned long pma; > > + unsigned long nocache; > > + unsigned long io; > > +} __svpbmt __cacheline_aligned; > > + > > +#define _PAGE_MASK __svpbmt.mask > > +#define _PAGE_PMA __svpbmt.pma > > +#define _PAGE_NOCACHE __svpbmt.nocache > > +#define _PAGE_IO __svpbmt.io > > +#else > > +#define _PAGE_MASK 0 > > +#define _PAGE_PMA 0 > > +#define _PAGE_NOCACHE 0 > > +#define _PAGE_IO 0 > > +#endif /* !__ASSEMBLY__ && CONFIG_64BIT */ > > + > > #define _PAGE_SPECIAL _PAGE_SOFT > > #define _PAGE_TABLE _PAGE_PRESENT > > > > @@ -38,7 +72,8 @@ > > /* Set of bits to preserve across pte_modify() */ > > #define _PAGE_CHG_MASK (~(unsigned long)(_PAGE_PRESENT | _PAGE_READ | \ > > _PAGE_WRITE | _PAGE_EXEC | \ > > - _PAGE_USER | _PAGE_GLOBAL)) > > + _PAGE_USER | _PAGE_GLOBAL | \ > > + _PAGE_MASK)) > > /* > > * when all of R/W/X are zero, the PTE is a pointer to the next level > > * of the page table; otherwise, it is a leaf PTE. > > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h > > index bf204e7c1f74..0f7a6541015f 100644 > > --- a/arch/riscv/include/asm/pgtable.h > > +++ b/arch/riscv/include/asm/pgtable.h > > @@ -138,7 +138,8 @@ > > | _PAGE_PRESENT \ > > | _PAGE_ACCESSED \ > > | _PAGE_DIRTY \ > > - | _PAGE_GLOBAL) > > + | _PAGE_GLOBAL \ > > + | _PAGE_PMA) > > > > #define PAGE_KERNEL __pgprot(_PAGE_KERNEL) > > #define PAGE_KERNEL_READ __pgprot(_PAGE_KERNEL & ~_PAGE_WRITE) > > @@ -148,11 +149,9 @@ > > > > #define PAGE_TABLE __pgprot(_PAGE_TABLE) > > > > -/* > > - * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't > > - * change the properties of memory regions. > > - */ > > -#define _PAGE_IOREMAP _PAGE_KERNEL > > +#define _PAGE_IOREMAP ((_PAGE_KERNEL & ~_PAGE_MASK) | _PAGE_IO) > > + > > +#define PAGE_IOREMAP __pgprot(_PAGE_IOREMAP) > > > > extern pgd_t swapper_pg_dir[]; > > > > @@ -232,12 +231,12 @@ static inline unsigned long _pgd_pfn(pgd_t pgd) > > > > static inline struct page *pmd_page(pmd_t pmd) > > { > > - return pfn_to_page(pmd_val(pmd) >> _PAGE_PFN_SHIFT); > > + return pfn_to_page(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT); > > } > > > > static inline unsigned long pmd_page_vaddr(pmd_t pmd) > > { > > - return (unsigned long)pfn_to_virt(pmd_val(pmd) >> _PAGE_PFN_SHIFT); > > + return (unsigned long)pfn_to_virt(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT); > > } > > > > static inline pte_t pmd_pte(pmd_t pmd) > > @@ -253,7 +252,7 @@ static inline pte_t pud_pte(pud_t pud) > > /* Yields the page frame number (PFN) of a page table entry */ > > static inline unsigned long pte_pfn(pte_t pte) > > { > > - return (pte_val(pte) >> _PAGE_PFN_SHIFT); > > + return (_chg_of_pte(pte) >> _PAGE_PFN_SHIFT); > > } > > > > #define pte_page(x) pfn_to_page(pte_pfn(x)) > > @@ -492,6 +491,28 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma, > > return ptep_test_and_clear_young(vma, address, ptep); > > } > > > > +#define pgprot_noncached pgprot_noncached > > +static inline pgprot_t pgprot_noncached(pgprot_t _prot) > > +{ > > + unsigned long prot = pgprot_val(_prot); > > + > > + prot &= ~_PAGE_MASK; > > + prot |= _PAGE_IO; > > + > > + return __pgprot(prot); > > +} > > + > > +#define pgprot_writecombine pgprot_writecombine > > +static inline pgprot_t pgprot_writecombine(pgprot_t _prot) > > +{ > > + unsigned long prot = pgprot_val(_prot); > > + > > + prot &= ~_PAGE_MASK; > > + prot |= _PAGE_NOCACHE; > > + > > + return __pgprot(prot); > > +} > > + > > /* > > * THP functions > > */ > > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c > > index d959d207a40d..fa7480cb8b87 100644 > > --- a/arch/riscv/kernel/cpufeature.c > > +++ b/arch/riscv/kernel/cpufeature.c > > @@ -8,6 +8,7 @@ > > > > #include <linux/bitmap.h> > > #include <linux/of.h> > > +#include <linux/pgtable.h> > > #include <asm/processor.h> > > #include <asm/hwcap.h> > > #include <asm/smp.h> > > @@ -59,6 +60,38 @@ bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit) > > } > > EXPORT_SYMBOL_GPL(__riscv_isa_extension_available); > > > > +static void __init mmu_supports_svpbmt(void) > > +{ > > +#if defined(CONFIG_MMU) && defined(CONFIG_64BIT) > > IIRC, Christoph suggested a CONFIG_RISCV_SVPBMT when reviewing v3. What > about that idea? Yes, sorry for missing it, yes, I think we can have something like this config ARCH_HAS_RISCV_SVPBMT bool default n any platform which needs this support, can just select ARCH_HAS_RISCV_SVPBMT and which is the best name? ARCH_HAS_RISCV_SVPBMT or just ARCH_HAS_SVPBMT ? > > > + struct device_node *node; > > + const char *str; > > + > > + for_each_of_cpu_node(node) { > > + if (of_property_read_string(node, "mmu-type", &str)) > > + continue; > > + > > + if (!strncmp(str + 6, "none", 4)) > > + continue; > > + > > + if (of_property_read_string(node, "mmu", &str)) > > + continue; > > + > > + if (strncmp(str + 6, "svpmbt", 6)) > > + continue; > > + } > > + > > + __svpbmt.pma = _SVPBMT_PMA; > > + __svpbmt.nocache = _SVPBMT_NC; > > + __svpbmt.io = _SVPBMT_IO; > > + __svpbmt.mask = _SVPBMT_MASK; > > +#endif > > +} > > + > > +static void __init mmu_supports(void) > > can we remove this function currently? Instead, directly call > mmu_supports_svpbmt()? > > > +{ > > + mmu_supports_svpbmt(); > > +} > > + > > void __init riscv_fill_hwcap(void) > > { > > struct device_node *node; > > @@ -67,6 +100,8 @@ void __init riscv_fill_hwcap(void) > > size_t i, j, isa_len; > > static unsigned long isa2hwcap[256] = {0}; > > > > + mmu_supports(); > > + > > isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I; > > isa2hwcap['m'] = isa2hwcap['M'] = COMPAT_HWCAP_ISA_M; > > isa2hwcap['a'] = isa2hwcap['A'] = COMPAT_HWCAP_ISA_A; > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c > > index 24b2b8044602..e4e658165ee1 100644 > > --- a/arch/riscv/mm/init.c > > +++ b/arch/riscv/mm/init.c > > @@ -854,3 +854,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, > > return vmemmap_populate_basepages(start, end, node, NULL); > > } > > #endif > > + > > +#if defined(CONFIG_64BIT) > > +struct __svpbmt_struct __svpbmt __ro_after_init; > > Added the structure for all RV64 including NOMMU case and those platforms > which doen't want SVPBMT at all, I believe Christoph's CONFIG_RISCV_SVPBMT > suggestion can solve this problem. see ARCH_HAS_RISCV_SVPBMT above . :-) > > > +EXPORT_SYMBOL(__svpbmt); > > +#endif > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports 2021-12-01 5:05 ` Wei Fu @ 2021-12-01 6:18 ` Anup Patel 2021-12-01 13:29 ` Jisheng Zhang 2021-12-03 9:12 ` Wei Fu 0 siblings, 2 replies; 35+ messages in thread From: Anup Patel @ 2021-12-01 6:18 UTC (permalink / raw) To: Wei Fu Cc: Jisheng Zhang, Anup Patel, atish patra, Palmer Dabbelt, Guo Ren, Christoph Müllner, Philipp Tomsich, Christoph Hellwig, Liu Shaohua, Wei Wu (吴伟), Drew Fustini, linux-riscv, Linux Kernel Mailing List, taiten.peng, Aniket Ponkshe, Heinrich Schuchardt, Gordan Markus, Guo Ren, Arnd Bergmann, Chen-Yu Tsai, Maxime Ripard, Daniel Lustig, Greg Favor, Andrea Mondelli, Jonathan Behrens, Xinhaoqu, Bill Huffman, Nick Kossifidis, Allen Baum, Josh Scheid, Richard Trauben On Wed, Dec 1, 2021 at 10:35 AM Wei Fu <wefu@redhat.com> wrote: > > Hi, Jisheng Zhang, > > On Mon, Nov 29, 2021 at 9:44 PM Jisheng Zhang <jszhang@kernel.org> wrote: > > > > On Mon, 29 Nov 2021 09:40:07 +0800 > > wefu@redhat.com wrote: > > > > > From: Wei Fu <wefu@redhat.com> > > > > > > This patch follows the standard pure RISC-V Svpbmt extension in > > > privilege spec to solve the non-coherent SOC dma synchronization > > > issues. > > > > > > Here is the svpbmt PTE format: > > > | 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > > > N MT RSW D A G U X W R V > > > ^ > > > > > > Of the Reserved bits [63:54] in a leaf PTE, the high bit is already > > > allocated (as the N bit), so bits [62:61] are used as the MT (aka > > > MemType) field. This field specifies one of three memory types that > > > are close equivalents (or equivalent in effect) to the three main x86 > > > and ARMv8 memory types - as shown in the following table. > > > > > > RISC-V > > > Encoding & > > > MemType RISC-V Description > > > ---------- ------------------------------------------------ > > > 00 - PMA Normal Cacheable, No change to implied PMA memory type > > > 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory > > > 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory > > > 11 - Rsvd Reserved for future standard use > > > > > > The standard protection_map[] needn't be modified because the "PMA" > > > type keeps the highest bits zero. And the whole modification is > > > limited in the arch/riscv/* and using a global variable > > > (__svpbmt) as _PAGE_MASK/IO/NOCACHE for pgprot_noncached > > > (&writecombine) in pgtable.h. We also add _PAGE_CHG_MASK to filter > > > PFN than before. > > > > > > Enable it in devicetree - (Add "riscv,svpbmt" in the mmu of cpu node) > > > - mmu: > > > riscv,svpmbt > > > > > > Signed-off-by: Wei Fu <wefu@redhat.com> > > > Co-developed-by: Liu Shaohua <liush@allwinnertech.com> > > > Signed-off-by: Liu Shaohua <liush@allwinnertech.com> > > > Co-developed-by: Guo Ren <guoren@kernel.org> > > > Signed-off-by: Guo Ren <guoren@kernel.org> > > > Cc: Palmer Dabbelt <palmerdabbelt@google.com> > > > Cc: Christoph Hellwig <hch@lst.de> > > > Cc: Anup Patel <anup.patel@wdc.com> > > > Cc: Arnd Bergmann <arnd@arndb.de> > > > Cc: Atish Patra <atish.patra@wdc.com> > > > Cc: Drew Fustini <drew@beagleboard.org> > > > Cc: Wei Fu <wefu@redhat.com> > > > Cc: Wei Wu <lazyparser@gmail.com> > > > Cc: Chen-Yu Tsai <wens@csie.org> > > > Cc: Maxime Ripard <maxime@cerno.tech> > > > Cc: Daniel Lustig <dlustig@nvidia.com> > > > Cc: Greg Favor <gfavor@ventanamicro.com> > > > Cc: Andrea Mondelli <andrea.mondelli@huawei.com> > > > Cc: Jonathan Behrens <behrensj@mit.edu> > > > Cc: Xinhaoqu (Freddie) <xinhaoqu@huawei.com> > > > Cc: Bill Huffman <huffman@cadence.com> > > > Cc: Nick Kossifidis <mick@ics.forth.gr> > > > Cc: Allen Baum <allen.baum@esperantotech.com> > > > Cc: Josh Scheid <jscheid@ventanamicro.com> > > > Cc: Richard Trauben <rtrauben@gmail.com> > > > --- > > > arch/riscv/include/asm/fixmap.h | 2 +- > > > arch/riscv/include/asm/pgtable-64.h | 21 ++++++++++++--- > > > arch/riscv/include/asm/pgtable-bits.h | 39 +++++++++++++++++++++++++-- > > > arch/riscv/include/asm/pgtable.h | 39 ++++++++++++++++++++------- > > > arch/riscv/kernel/cpufeature.c | 35 ++++++++++++++++++++++++ > > > arch/riscv/mm/init.c | 5 ++++ > > > 6 files changed, 126 insertions(+), 15 deletions(-) > > > > > > diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h > > > index 54cbf07fb4e9..5acd99d08e74 100644 > > > --- a/arch/riscv/include/asm/fixmap.h > > > +++ b/arch/riscv/include/asm/fixmap.h > > > @@ -43,7 +43,7 @@ enum fixed_addresses { > > > __end_of_fixed_addresses > > > }; > > > > > > -#define FIXMAP_PAGE_IO PAGE_KERNEL > > > +#define FIXMAP_PAGE_IO PAGE_IOREMAP > > > > > > #define __early_set_fixmap __set_fixmap > > > > > > diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h > > > index 228261aa9628..16d251282b1d 100644 > > > --- a/arch/riscv/include/asm/pgtable-64.h > > > +++ b/arch/riscv/include/asm/pgtable-64.h > > > @@ -59,14 +59,29 @@ static inline void pud_clear(pud_t *pudp) > > > set_pud(pudp, __pud(0)); > > > } > > > > > > +static inline unsigned long _chg_of_pmd(pmd_t pmd) > > > +{ > > > + return (pmd_val(pmd) & _PAGE_CHG_MASK); > > > +} > > > + > > > +static inline unsigned long _chg_of_pud(pud_t pud) > > > +{ > > > + return (pud_val(pud) & _PAGE_CHG_MASK); > > > +} > > > + > > > +static inline unsigned long _chg_of_pte(pte_t pte) > > > +{ > > > + return (pte_val(pte) & _PAGE_CHG_MASK); > > > +} > > > + > > > static inline pmd_t *pud_pgtable(pud_t pud) > > > { > > > - return (pmd_t *)pfn_to_virt(pud_val(pud) >> _PAGE_PFN_SHIFT); > > > + return (pmd_t *)pfn_to_virt(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT); > > > } > > > > > > static inline struct page *pud_page(pud_t pud) > > > { > > > - return pfn_to_page(pud_val(pud) >> _PAGE_PFN_SHIFT); > > > + return pfn_to_page(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT); > > > } > > > > > > static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot) > > > @@ -76,7 +91,7 @@ static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot) > > > > > > static inline unsigned long _pmd_pfn(pmd_t pmd) > > > { > > > - return pmd_val(pmd) >> _PAGE_PFN_SHIFT; > > > + return _chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT; > > > } > > > > > > #define mk_pmd(page, prot) pfn_pmd(page_to_pfn(page), prot) > > > diff --git a/arch/riscv/include/asm/pgtable-bits.h b/arch/riscv/include/asm/pgtable-bits.h > > > index 2ee413912926..e5b0fce4ddc5 100644 > > > --- a/arch/riscv/include/asm/pgtable-bits.h > > > +++ b/arch/riscv/include/asm/pgtable-bits.h > > > @@ -7,7 +7,7 @@ > > > #define _ASM_RISCV_PGTABLE_BITS_H > > > > > > /* > > > - * PTE format: > > > + * rv32 PTE format: > > > * | XLEN-1 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > > > * PFN reserved for SW D A G U X W R V > > > */ > > > @@ -24,6 +24,40 @@ > > > #define _PAGE_DIRTY (1 << 7) /* Set by hardware on any write */ > > > #define _PAGE_SOFT (1 << 8) /* Reserved for software */ > > > > > > +#if !defined(__ASSEMBLY__) && defined(CONFIG_64BIT) > > > +/* > > > + * rv64 PTE format: > > > + * | 63 | 62 61 | 60 54 | 53 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > > > + * N MT RSV PFN reserved for SW D A G U X W R V > > > + * [62:61] Memory Type definitions: > > > + * 00 - PMA Normal Cacheable, No change to implied PMA memory type > > > + * 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory > > > + * 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory > > > + * 11 - Rsvd Reserved for future standard use > > > + */ > > > +#define _SVPBMT_PMA 0UL > > > +#define _SVPBMT_NC (1UL << 61) > > > +#define _SVPBMT_IO (1UL << 62) > > > +#define _SVPBMT_MASK (_SVPBMT_NC | _SVPBMT_IO) > > > + > > > +extern struct __svpbmt_struct { > > > + unsigned long mask; > > > + unsigned long pma; > > > + unsigned long nocache; > > > + unsigned long io; > > > +} __svpbmt __cacheline_aligned; > > > + > > > +#define _PAGE_MASK __svpbmt.mask > > > +#define _PAGE_PMA __svpbmt.pma > > > +#define _PAGE_NOCACHE __svpbmt.nocache > > > +#define _PAGE_IO __svpbmt.io > > > +#else > > > +#define _PAGE_MASK 0 > > > +#define _PAGE_PMA 0 > > > +#define _PAGE_NOCACHE 0 > > > +#define _PAGE_IO 0 > > > +#endif /* !__ASSEMBLY__ && CONFIG_64BIT */ > > > + > > > #define _PAGE_SPECIAL _PAGE_SOFT > > > #define _PAGE_TABLE _PAGE_PRESENT > > > > > > @@ -38,7 +72,8 @@ > > > /* Set of bits to preserve across pte_modify() */ > > > #define _PAGE_CHG_MASK (~(unsigned long)(_PAGE_PRESENT | _PAGE_READ | \ > > > _PAGE_WRITE | _PAGE_EXEC | \ > > > - _PAGE_USER | _PAGE_GLOBAL)) > > > + _PAGE_USER | _PAGE_GLOBAL | \ > > > + _PAGE_MASK)) > > > /* > > > * when all of R/W/X are zero, the PTE is a pointer to the next level > > > * of the page table; otherwise, it is a leaf PTE. > > > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h > > > index bf204e7c1f74..0f7a6541015f 100644 > > > --- a/arch/riscv/include/asm/pgtable.h > > > +++ b/arch/riscv/include/asm/pgtable.h > > > @@ -138,7 +138,8 @@ > > > | _PAGE_PRESENT \ > > > | _PAGE_ACCESSED \ > > > | _PAGE_DIRTY \ > > > - | _PAGE_GLOBAL) > > > + | _PAGE_GLOBAL \ > > > + | _PAGE_PMA) > > > > > > #define PAGE_KERNEL __pgprot(_PAGE_KERNEL) > > > #define PAGE_KERNEL_READ __pgprot(_PAGE_KERNEL & ~_PAGE_WRITE) > > > @@ -148,11 +149,9 @@ > > > > > > #define PAGE_TABLE __pgprot(_PAGE_TABLE) > > > > > > -/* > > > - * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't > > > - * change the properties of memory regions. > > > - */ > > > -#define _PAGE_IOREMAP _PAGE_KERNEL > > > +#define _PAGE_IOREMAP ((_PAGE_KERNEL & ~_PAGE_MASK) | _PAGE_IO) > > > + > > > +#define PAGE_IOREMAP __pgprot(_PAGE_IOREMAP) > > > > > > extern pgd_t swapper_pg_dir[]; > > > > > > @@ -232,12 +231,12 @@ static inline unsigned long _pgd_pfn(pgd_t pgd) > > > > > > static inline struct page *pmd_page(pmd_t pmd) > > > { > > > - return pfn_to_page(pmd_val(pmd) >> _PAGE_PFN_SHIFT); > > > + return pfn_to_page(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT); > > > } > > > > > > static inline unsigned long pmd_page_vaddr(pmd_t pmd) > > > { > > > - return (unsigned long)pfn_to_virt(pmd_val(pmd) >> _PAGE_PFN_SHIFT); > > > + return (unsigned long)pfn_to_virt(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT); > > > } > > > > > > static inline pte_t pmd_pte(pmd_t pmd) > > > @@ -253,7 +252,7 @@ static inline pte_t pud_pte(pud_t pud) > > > /* Yields the page frame number (PFN) of a page table entry */ > > > static inline unsigned long pte_pfn(pte_t pte) > > > { > > > - return (pte_val(pte) >> _PAGE_PFN_SHIFT); > > > + return (_chg_of_pte(pte) >> _PAGE_PFN_SHIFT); > > > } > > > > > > #define pte_page(x) pfn_to_page(pte_pfn(x)) > > > @@ -492,6 +491,28 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma, > > > return ptep_test_and_clear_young(vma, address, ptep); > > > } > > > > > > +#define pgprot_noncached pgprot_noncached > > > +static inline pgprot_t pgprot_noncached(pgprot_t _prot) > > > +{ > > > + unsigned long prot = pgprot_val(_prot); > > > + > > > + prot &= ~_PAGE_MASK; > > > + prot |= _PAGE_IO; > > > + > > > + return __pgprot(prot); > > > +} > > > + > > > +#define pgprot_writecombine pgprot_writecombine > > > +static inline pgprot_t pgprot_writecombine(pgprot_t _prot) > > > +{ > > > + unsigned long prot = pgprot_val(_prot); > > > + > > > + prot &= ~_PAGE_MASK; > > > + prot |= _PAGE_NOCACHE; > > > + > > > + return __pgprot(prot); > > > +} > > > + > > > /* > > > * THP functions > > > */ > > > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c > > > index d959d207a40d..fa7480cb8b87 100644 > > > --- a/arch/riscv/kernel/cpufeature.c > > > +++ b/arch/riscv/kernel/cpufeature.c > > > @@ -8,6 +8,7 @@ > > > > > > #include <linux/bitmap.h> > > > #include <linux/of.h> > > > +#include <linux/pgtable.h> > > > #include <asm/processor.h> > > > #include <asm/hwcap.h> > > > #include <asm/smp.h> > > > @@ -59,6 +60,38 @@ bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit) > > > } > > > EXPORT_SYMBOL_GPL(__riscv_isa_extension_available); > > > > > > +static void __init mmu_supports_svpbmt(void) > > > +{ > > > +#if defined(CONFIG_MMU) && defined(CONFIG_64BIT) > > > > IIRC, Christoph suggested a CONFIG_RISCV_SVPBMT when reviewing v3. What > > about that idea? > > Yes, sorry for missing it, yes, I think we can have something like this > > config ARCH_HAS_RISCV_SVPBMT > bool > default n > > any platform which needs this support, can just > > select ARCH_HAS_RISCV_SVPBMT > > and which is the best name? ARCH_HAS_RISCV_SVPBMT or just ARCH_HAS_SVPBMT ? > > > > > > + struct device_node *node; > > > + const char *str; > > > + > > > + for_each_of_cpu_node(node) { > > > + if (of_property_read_string(node, "mmu-type", &str)) > > > + continue; > > > + > > > + if (!strncmp(str + 6, "none", 4)) > > > + continue; > > > + > > > + if (of_property_read_string(node, "mmu", &str)) > > > + continue; > > > + > > > + if (strncmp(str + 6, "svpmbt", 6)) > > > + continue; > > > + } > > > + > > > + __svpbmt.pma = _SVPBMT_PMA; > > > + __svpbmt.nocache = _SVPBMT_NC; > > > + __svpbmt.io = _SVPBMT_IO; > > > + __svpbmt.mask = _SVPBMT_MASK; > > > +#endif > > > +} > > > + > > > +static void __init mmu_supports(void) > > > > can we remove this function currently? Instead, directly call > > mmu_supports_svpbmt()? > > > > > +{ > > > + mmu_supports_svpbmt(); > > > +} > > > + > > > void __init riscv_fill_hwcap(void) > > > { > > > struct device_node *node; > > > @@ -67,6 +100,8 @@ void __init riscv_fill_hwcap(void) > > > size_t i, j, isa_len; > > > static unsigned long isa2hwcap[256] = {0}; > > > > > > + mmu_supports(); > > > + > > > isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I; > > > isa2hwcap['m'] = isa2hwcap['M'] = COMPAT_HWCAP_ISA_M; > > > isa2hwcap['a'] = isa2hwcap['A'] = COMPAT_HWCAP_ISA_A; > > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c > > > index 24b2b8044602..e4e658165ee1 100644 > > > --- a/arch/riscv/mm/init.c > > > +++ b/arch/riscv/mm/init.c > > > @@ -854,3 +854,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, > > > return vmemmap_populate_basepages(start, end, node, NULL); > > > } > > > #endif > > > + > > > +#if defined(CONFIG_64BIT) > > > +struct __svpbmt_struct __svpbmt __ro_after_init; > > > > Added the structure for all RV64 including NOMMU case and those platforms > > which doen't want SVPBMT at all, I believe Christoph's CONFIG_RISCV_SVPBMT > > suggestion can solve this problem. > > see ARCH_HAS_RISCV_SVPBMT above . :-) This config option will not align with the goal of having a unified kernel image which works on HW with/without Svpmbt. Better to explore code patching approaches which have zero overhead. Regards, Anup > > > > > > +EXPORT_SYMBOL(__svpbmt); > > > +#endif > > > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports 2021-12-01 6:18 ` Anup Patel @ 2021-12-01 13:29 ` Jisheng Zhang 2021-12-03 9:12 ` Wei Fu 1 sibling, 0 replies; 35+ messages in thread From: Jisheng Zhang @ 2021-12-01 13:29 UTC (permalink / raw) To: Anup Patel Cc: Wei Fu, Anup Patel, atish patra, Palmer Dabbelt, Guo Ren, Christoph Müllner, Philipp Tomsich, Christoph Hellwig, Liu Shaohua, Wei Wu (吴伟), Drew Fustini, linux-riscv, Linux Kernel Mailing List, taiten.peng, Aniket Ponkshe, Heinrich Schuchardt, Gordan Markus, Guo Ren, Arnd Bergmann, Chen-Yu Tsai, Maxime Ripard, Daniel Lustig, Greg Favor, Andrea Mondelli, Jonathan Behrens, Xinhaoqu, Bill Huffman, Nick Kossifidis, Allen Baum, Josh Scheid, Richard Trauben On Wed, 1 Dec 2021 11:48:44 +0530 Anup Patel <anup@brainfault.org> wrote: > > > > */ > > > > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c > > > > index d959d207a40d..fa7480cb8b87 100644 > > > > --- a/arch/riscv/kernel/cpufeature.c > > > > +++ b/arch/riscv/kernel/cpufeature.c > > > > @@ -8,6 +8,7 @@ > > > > > > > > #include <linux/bitmap.h> > > > > #include <linux/of.h> > > > > +#include <linux/pgtable.h> > > > > #include <asm/processor.h> > > > > #include <asm/hwcap.h> > > > > #include <asm/smp.h> > > > > @@ -59,6 +60,38 @@ bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit) > > > > } > > > > EXPORT_SYMBOL_GPL(__riscv_isa_extension_available); > > > > > > > > +static void __init mmu_supports_svpbmt(void) > > > > +{ > > > > +#if defined(CONFIG_MMU) && defined(CONFIG_64BIT) > > > > > > IIRC, Christoph suggested a CONFIG_RISCV_SVPBMT when reviewing v3. What > > > about that idea? > > > > Yes, sorry for missing it, yes, I think we can have something like this > > > > config ARCH_HAS_RISCV_SVPBMT > > bool > > default n > > > > any platform which needs this support, can just > > > > select ARCH_HAS_RISCV_SVPBMT > > > > and which is the best name? ARCH_HAS_RISCV_SVPBMT or just ARCH_HAS_SVPBMT ? > > > > > > > > > + struct device_node *node; > > > > + const char *str; > > > > + > > > > + for_each_of_cpu_node(node) { > > > > + if (of_property_read_string(node, "mmu-type", &str)) > > > > + continue; > > > > + > > > > + if (!strncmp(str + 6, "none", 4)) > > > > + continue; > > > > + > > > > + if (of_property_read_string(node, "mmu", &str)) > > > > + continue; > > > > + > > > > + if (strncmp(str + 6, "svpmbt", 6)) > > > > + continue; > > > > + } > > > > + > > > > + __svpbmt.pma = _SVPBMT_PMA; > > > > + __svpbmt.nocache = _SVPBMT_NC; > > > > + __svpbmt.io = _SVPBMT_IO; > > > > + __svpbmt.mask = _SVPBMT_MASK; > > > > +#endif > > > > +} > > > > + > > > > +static void __init mmu_supports(void) > > > > > > can we remove this function currently? Instead, directly call > > > mmu_supports_svpbmt()? > > > > > > > +{ > > > > + mmu_supports_svpbmt(); > > > > +} > > > > + > > > > void __init riscv_fill_hwcap(void) > > > > { > > > > struct device_node *node; > > > > @@ -67,6 +100,8 @@ void __init riscv_fill_hwcap(void) > > > > size_t i, j, isa_len; > > > > static unsigned long isa2hwcap[256] = {0}; > > > > > > > > + mmu_supports(); > > > > + > > > > isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I; > > > > isa2hwcap['m'] = isa2hwcap['M'] = COMPAT_HWCAP_ISA_M; > > > > isa2hwcap['a'] = isa2hwcap['A'] = COMPAT_HWCAP_ISA_A; > > > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c > > > > index 24b2b8044602..e4e658165ee1 100644 > > > > --- a/arch/riscv/mm/init.c > > > > +++ b/arch/riscv/mm/init.c > > > > @@ -854,3 +854,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, > > > > return vmemmap_populate_basepages(start, end, node, NULL); > > > > } > > > > #endif > > > > + > > > > +#if defined(CONFIG_64BIT) > > > > +struct __svpbmt_struct __svpbmt __ro_after_init; > > > > > > Added the structure for all RV64 including NOMMU case and those platforms > > > which doen't want SVPBMT at all, I believe Christoph's CONFIG_RISCV_SVPBMT > > > suggestion can solve this problem. > > > > see ARCH_HAS_RISCV_SVPBMT above . :-) > > This config option will not align with the goal of having a unified > kernel image which works on HW with/without Svpmbt. Just my thoughts: If disable this option, HW without Svpbmt can work as before; Hw with Svpbmt will only have a basic working, those DMA etc can't work. If enable this option, HW without Svpbmt can work as well, but with a bit overhead and waste. HW with Svpbmt can work. So this option gives those platforms which doesn't need Svpbmt a chance to totally disable it. But linux distributions which want a uniified Image usually enable features as much as possible, so IMHO, this config option can still meet unified kernel image requirement. > > Better to explore code patching approaches which have zero > overhead. It would be nice if the Svpbmt can be supported via. coding patching tech. Thanks ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports 2021-12-01 6:18 ` Anup Patel 2021-12-01 13:29 ` Jisheng Zhang @ 2021-12-03 9:12 ` Wei Fu 1 sibling, 0 replies; 35+ messages in thread From: Wei Fu @ 2021-12-03 9:12 UTC (permalink / raw) To: Anup Patel Cc: Jisheng Zhang, Anup Patel, atish patra, Palmer Dabbelt, Guo Ren, Christoph Müllner, Philipp Tomsich, Christoph Hellwig, Liu Shaohua, Wei Wu (吴伟), Drew Fustini, linux-riscv, Linux Kernel Mailing List, taiten.peng, Aniket Ponkshe, Heinrich Schuchardt, Gordan Markus, Guo Ren, Arnd Bergmann, Chen-Yu Tsai, Maxime Ripard, Daniel Lustig, Greg Favor, Andrea Mondelli, Jonathan Behrens, Xinhaoqu, Bill Huffman, Nick Kossifidis, Allen Baum, Josh Scheid, Richard Trauben Hi Anup, On Wed, Dec 1, 2021 at 2:19 PM Anup Patel <anup@brainfault.org> wrote: > > On Wed, Dec 1, 2021 at 10:35 AM Wei Fu <wefu@redhat.com> wrote: > > > > Hi, Jisheng Zhang, > > > > On Mon, Nov 29, 2021 at 9:44 PM Jisheng Zhang <jszhang@kernel.org> wrote: > > > > > > On Mon, 29 Nov 2021 09:40:07 +0800 > > > wefu@redhat.com wrote: > > > > > > > From: Wei Fu <wefu@redhat.com> > > > > > > > > This patch follows the standard pure RISC-V Svpbmt extension in > > > > privilege spec to solve the non-coherent SOC dma synchronization > > > > issues. > > > > > > > > Here is the svpbmt PTE format: > > > > | 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > > > > N MT RSW D A G U X W R V > > > > ^ > > > > > > > > Of the Reserved bits [63:54] in a leaf PTE, the high bit is already > > > > allocated (as the N bit), so bits [62:61] are used as the MT (aka > > > > MemType) field. This field specifies one of three memory types that > > > > are close equivalents (or equivalent in effect) to the three main x86 > > > > and ARMv8 memory types - as shown in the following table. > > > > > > > > RISC-V > > > > Encoding & > > > > MemType RISC-V Description > > > > ---------- ------------------------------------------------ > > > > 00 - PMA Normal Cacheable, No change to implied PMA memory type > > > > 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory > > > > 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory > > > > 11 - Rsvd Reserved for future standard use > > > > > > > > The standard protection_map[] needn't be modified because the "PMA" > > > > type keeps the highest bits zero. And the whole modification is > > > > limited in the arch/riscv/* and using a global variable > > > > (__svpbmt) as _PAGE_MASK/IO/NOCACHE for pgprot_noncached > > > > (&writecombine) in pgtable.h. We also add _PAGE_CHG_MASK to filter > > > > PFN than before. > > > > > > > > Enable it in devicetree - (Add "riscv,svpbmt" in the mmu of cpu node) > > > > - mmu: > > > > riscv,svpmbt > > > > > > > > Signed-off-by: Wei Fu <wefu@redhat.com> > > > > Co-developed-by: Liu Shaohua <liush@allwinnertech.com> > > > > Signed-off-by: Liu Shaohua <liush@allwinnertech.com> > > > > Co-developed-by: Guo Ren <guoren@kernel.org> > > > > Signed-off-by: Guo Ren <guoren@kernel.org> > > > > Cc: Palmer Dabbelt <palmerdabbelt@google.com> > > > > Cc: Christoph Hellwig <hch@lst.de> > > > > Cc: Anup Patel <anup.patel@wdc.com> > > > > Cc: Arnd Bergmann <arnd@arndb.de> > > > > Cc: Atish Patra <atish.patra@wdc.com> > > > > Cc: Drew Fustini <drew@beagleboard.org> > > > > Cc: Wei Fu <wefu@redhat.com> > > > > Cc: Wei Wu <lazyparser@gmail.com> > > > > Cc: Chen-Yu Tsai <wens@csie.org> > > > > Cc: Maxime Ripard <maxime@cerno.tech> > > > > Cc: Daniel Lustig <dlustig@nvidia.com> > > > > Cc: Greg Favor <gfavor@ventanamicro.com> > > > > Cc: Andrea Mondelli <andrea.mondelli@huawei.com> > > > > Cc: Jonathan Behrens <behrensj@mit.edu> > > > > Cc: Xinhaoqu (Freddie) <xinhaoqu@huawei.com> > > > > Cc: Bill Huffman <huffman@cadence.com> > > > > Cc: Nick Kossifidis <mick@ics.forth.gr> > > > > Cc: Allen Baum <allen.baum@esperantotech.com> > > > > Cc: Josh Scheid <jscheid@ventanamicro.com> > > > > Cc: Richard Trauben <rtrauben@gmail.com> > > > > --- > > > > arch/riscv/include/asm/fixmap.h | 2 +- > > > > arch/riscv/include/asm/pgtable-64.h | 21 ++++++++++++--- > > > > arch/riscv/include/asm/pgtable-bits.h | 39 +++++++++++++++++++++++++-- > > > > arch/riscv/include/asm/pgtable.h | 39 ++++++++++++++++++++------- > > > > arch/riscv/kernel/cpufeature.c | 35 ++++++++++++++++++++++++ > > > > arch/riscv/mm/init.c | 5 ++++ > > > > 6 files changed, 126 insertions(+), 15 deletions(-) > > > > > > > > diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h > > > > index 54cbf07fb4e9..5acd99d08e74 100644 > > > > --- a/arch/riscv/include/asm/fixmap.h > > > > +++ b/arch/riscv/include/asm/fixmap.h > > > > @@ -43,7 +43,7 @@ enum fixed_addresses { > > > > __end_of_fixed_addresses > > > > }; > > > > > > > > -#define FIXMAP_PAGE_IO PAGE_KERNEL > > > > +#define FIXMAP_PAGE_IO PAGE_IOREMAP > > > > > > > > #define __early_set_fixmap __set_fixmap > > > > > > > > diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h > > > > index 228261aa9628..16d251282b1d 100644 > > > > --- a/arch/riscv/include/asm/pgtable-64.h > > > > +++ b/arch/riscv/include/asm/pgtable-64.h > > > > @@ -59,14 +59,29 @@ static inline void pud_clear(pud_t *pudp) > > > > set_pud(pudp, __pud(0)); > > > > } > > > > > > > > +static inline unsigned long _chg_of_pmd(pmd_t pmd) > > > > +{ > > > > + return (pmd_val(pmd) & _PAGE_CHG_MASK); > > > > +} > > > > + > > > > +static inline unsigned long _chg_of_pud(pud_t pud) > > > > +{ > > > > + return (pud_val(pud) & _PAGE_CHG_MASK); > > > > +} > > > > + > > > > +static inline unsigned long _chg_of_pte(pte_t pte) > > > > +{ > > > > + return (pte_val(pte) & _PAGE_CHG_MASK); > > > > +} > > > > + > > > > static inline pmd_t *pud_pgtable(pud_t pud) > > > > { > > > > - return (pmd_t *)pfn_to_virt(pud_val(pud) >> _PAGE_PFN_SHIFT); > > > > + return (pmd_t *)pfn_to_virt(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT); > > > > } > > > > > > > > static inline struct page *pud_page(pud_t pud) > > > > { > > > > - return pfn_to_page(pud_val(pud) >> _PAGE_PFN_SHIFT); > > > > + return pfn_to_page(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT); > > > > } > > > > > > > > static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot) > > > > @@ -76,7 +91,7 @@ static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot) > > > > > > > > static inline unsigned long _pmd_pfn(pmd_t pmd) > > > > { > > > > - return pmd_val(pmd) >> _PAGE_PFN_SHIFT; > > > > + return _chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT; > > > > } > > > > > > > > #define mk_pmd(page, prot) pfn_pmd(page_to_pfn(page), prot) > > > > diff --git a/arch/riscv/include/asm/pgtable-bits.h b/arch/riscv/include/asm/pgtable-bits.h > > > > index 2ee413912926..e5b0fce4ddc5 100644 > > > > --- a/arch/riscv/include/asm/pgtable-bits.h > > > > +++ b/arch/riscv/include/asm/pgtable-bits.h > > > > @@ -7,7 +7,7 @@ > > > > #define _ASM_RISCV_PGTABLE_BITS_H > > > > > > > > /* > > > > - * PTE format: > > > > + * rv32 PTE format: > > > > * | XLEN-1 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > > > > * PFN reserved for SW D A G U X W R V > > > > */ > > > > @@ -24,6 +24,40 @@ > > > > #define _PAGE_DIRTY (1 << 7) /* Set by hardware on any write */ > > > > #define _PAGE_SOFT (1 << 8) /* Reserved for software */ > > > > > > > > +#if !defined(__ASSEMBLY__) && defined(CONFIG_64BIT) > > > > +/* > > > > + * rv64 PTE format: > > > > + * | 63 | 62 61 | 60 54 | 53 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > > > > + * N MT RSV PFN reserved for SW D A G U X W R V > > > > + * [62:61] Memory Type definitions: > > > > + * 00 - PMA Normal Cacheable, No change to implied PMA memory type > > > > + * 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory > > > > + * 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory > > > > + * 11 - Rsvd Reserved for future standard use > > > > + */ > > > > +#define _SVPBMT_PMA 0UL > > > > +#define _SVPBMT_NC (1UL << 61) > > > > +#define _SVPBMT_IO (1UL << 62) > > > > +#define _SVPBMT_MASK (_SVPBMT_NC | _SVPBMT_IO) > > > > + > > > > +extern struct __svpbmt_struct { > > > > + unsigned long mask; > > > > + unsigned long pma; > > > > + unsigned long nocache; > > > > + unsigned long io; > > > > +} __svpbmt __cacheline_aligned; > > > > + > > > > +#define _PAGE_MASK __svpbmt.mask > > > > +#define _PAGE_PMA __svpbmt.pma > > > > +#define _PAGE_NOCACHE __svpbmt.nocache > > > > +#define _PAGE_IO __svpbmt.io > > > > +#else > > > > +#define _PAGE_MASK 0 > > > > +#define _PAGE_PMA 0 > > > > +#define _PAGE_NOCACHE 0 > > > > +#define _PAGE_IO 0 > > > > +#endif /* !__ASSEMBLY__ && CONFIG_64BIT */ > > > > + > > > > #define _PAGE_SPECIAL _PAGE_SOFT > > > > #define _PAGE_TABLE _PAGE_PRESENT > > > > > > > > @@ -38,7 +72,8 @@ > > > > /* Set of bits to preserve across pte_modify() */ > > > > #define _PAGE_CHG_MASK (~(unsigned long)(_PAGE_PRESENT | _PAGE_READ | \ > > > > _PAGE_WRITE | _PAGE_EXEC | \ > > > > - _PAGE_USER | _PAGE_GLOBAL)) > > > > + _PAGE_USER | _PAGE_GLOBAL | \ > > > > + _PAGE_MASK)) > > > > /* > > > > * when all of R/W/X are zero, the PTE is a pointer to the next level > > > > * of the page table; otherwise, it is a leaf PTE. > > > > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h > > > > index bf204e7c1f74..0f7a6541015f 100644 > > > > --- a/arch/riscv/include/asm/pgtable.h > > > > +++ b/arch/riscv/include/asm/pgtable.h > > > > @@ -138,7 +138,8 @@ > > > > | _PAGE_PRESENT \ > > > > | _PAGE_ACCESSED \ > > > > | _PAGE_DIRTY \ > > > > - | _PAGE_GLOBAL) > > > > + | _PAGE_GLOBAL \ > > > > + | _PAGE_PMA) > > > > > > > > #define PAGE_KERNEL __pgprot(_PAGE_KERNEL) > > > > #define PAGE_KERNEL_READ __pgprot(_PAGE_KERNEL & ~_PAGE_WRITE) > > > > @@ -148,11 +149,9 @@ > > > > > > > > #define PAGE_TABLE __pgprot(_PAGE_TABLE) > > > > > > > > -/* > > > > - * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't > > > > - * change the properties of memory regions. > > > > - */ > > > > -#define _PAGE_IOREMAP _PAGE_KERNEL > > > > +#define _PAGE_IOREMAP ((_PAGE_KERNEL & ~_PAGE_MASK) | _PAGE_IO) > > > > + > > > > +#define PAGE_IOREMAP __pgprot(_PAGE_IOREMAP) > > > > > > > > extern pgd_t swapper_pg_dir[]; > > > > > > > > @@ -232,12 +231,12 @@ static inline unsigned long _pgd_pfn(pgd_t pgd) > > > > > > > > static inline struct page *pmd_page(pmd_t pmd) > > > > { > > > > - return pfn_to_page(pmd_val(pmd) >> _PAGE_PFN_SHIFT); > > > > + return pfn_to_page(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT); > > > > } > > > > > > > > static inline unsigned long pmd_page_vaddr(pmd_t pmd) > > > > { > > > > - return (unsigned long)pfn_to_virt(pmd_val(pmd) >> _PAGE_PFN_SHIFT); > > > > + return (unsigned long)pfn_to_virt(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT); > > > > } > > > > > > > > static inline pte_t pmd_pte(pmd_t pmd) > > > > @@ -253,7 +252,7 @@ static inline pte_t pud_pte(pud_t pud) > > > > /* Yields the page frame number (PFN) of a page table entry */ > > > > static inline unsigned long pte_pfn(pte_t pte) > > > > { > > > > - return (pte_val(pte) >> _PAGE_PFN_SHIFT); > > > > + return (_chg_of_pte(pte) >> _PAGE_PFN_SHIFT); > > > > } > > > > > > > > #define pte_page(x) pfn_to_page(pte_pfn(x)) > > > > @@ -492,6 +491,28 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma, > > > > return ptep_test_and_clear_young(vma, address, ptep); > > > > } > > > > > > > > +#define pgprot_noncached pgprot_noncached > > > > +static inline pgprot_t pgprot_noncached(pgprot_t _prot) > > > > +{ > > > > + unsigned long prot = pgprot_val(_prot); > > > > + > > > > + prot &= ~_PAGE_MASK; > > > > + prot |= _PAGE_IO; > > > > + > > > > + return __pgprot(prot); > > > > +} > > > > + > > > > +#define pgprot_writecombine pgprot_writecombine > > > > +static inline pgprot_t pgprot_writecombine(pgprot_t _prot) > > > > +{ > > > > + unsigned long prot = pgprot_val(_prot); > > > > + > > > > + prot &= ~_PAGE_MASK; > > > > + prot |= _PAGE_NOCACHE; > > > > + > > > > + return __pgprot(prot); > > > > +} > > > > + > > > > /* > > > > * THP functions > > > > */ > > > > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c > > > > index d959d207a40d..fa7480cb8b87 100644 > > > > --- a/arch/riscv/kernel/cpufeature.c > > > > +++ b/arch/riscv/kernel/cpufeature.c > > > > @@ -8,6 +8,7 @@ > > > > > > > > #include <linux/bitmap.h> > > > > #include <linux/of.h> > > > > +#include <linux/pgtable.h> > > > > #include <asm/processor.h> > > > > #include <asm/hwcap.h> > > > > #include <asm/smp.h> > > > > @@ -59,6 +60,38 @@ bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit) > > > > } > > > > EXPORT_SYMBOL_GPL(__riscv_isa_extension_available); > > > > > > > > +static void __init mmu_supports_svpbmt(void) > > > > +{ > > > > +#if defined(CONFIG_MMU) && defined(CONFIG_64BIT) > > > > > > IIRC, Christoph suggested a CONFIG_RISCV_SVPBMT when reviewing v3. What > > > about that idea? > > > > Yes, sorry for missing it, yes, I think we can have something like this > > > > config ARCH_HAS_RISCV_SVPBMT > > bool > > default n > > > > any platform which needs this support, can just > > > > select ARCH_HAS_RISCV_SVPBMT > > > > and which is the best name? ARCH_HAS_RISCV_SVPBMT or just ARCH_HAS_SVPBMT ? > > > > > > > > > + struct device_node *node; > > > > + const char *str; > > > > + > > > > + for_each_of_cpu_node(node) { > > > > + if (of_property_read_string(node, "mmu-type", &str)) > > > > + continue; > > > > + > > > > + if (!strncmp(str + 6, "none", 4)) > > > > + continue; > > > > + > > > > + if (of_property_read_string(node, "mmu", &str)) > > > > + continue; > > > > + > > > > + if (strncmp(str + 6, "svpmbt", 6)) > > > > + continue; > > > > + } > > > > + > > > > + __svpbmt.pma = _SVPBMT_PMA; > > > > + __svpbmt.nocache = _SVPBMT_NC; > > > > + __svpbmt.io = _SVPBMT_IO; > > > > + __svpbmt.mask = _SVPBMT_MASK; > > > > +#endif > > > > +} > > > > + > > > > +static void __init mmu_supports(void) > > > > > > can we remove this function currently? Instead, directly call > > > mmu_supports_svpbmt()? > > > > > > > +{ > > > > + mmu_supports_svpbmt(); > > > > +} > > > > + > > > > void __init riscv_fill_hwcap(void) > > > > { > > > > struct device_node *node; > > > > @@ -67,6 +100,8 @@ void __init riscv_fill_hwcap(void) > > > > size_t i, j, isa_len; > > > > static unsigned long isa2hwcap[256] = {0}; > > > > > > > > + mmu_supports(); > > > > + > > > > isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I; > > > > isa2hwcap['m'] = isa2hwcap['M'] = COMPAT_HWCAP_ISA_M; > > > > isa2hwcap['a'] = isa2hwcap['A'] = COMPAT_HWCAP_ISA_A; > > > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c > > > > index 24b2b8044602..e4e658165ee1 100644 > > > > --- a/arch/riscv/mm/init.c > > > > +++ b/arch/riscv/mm/init.c > > > > @@ -854,3 +854,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, > > > > return vmemmap_populate_basepages(start, end, node, NULL); > > > > } > > > > #endif > > > > + > > > > +#if defined(CONFIG_64BIT) > > > > +struct __svpbmt_struct __svpbmt __ro_after_init; > > > > > > Added the structure for all RV64 including NOMMU case and those platforms > > > which doen't want SVPBMT at all, I believe Christoph's CONFIG_RISCV_SVPBMT > > > suggestion can solve this problem. > > > > see ARCH_HAS_RISCV_SVPBMT above . :-) > > This config option will not align with the goal of having a unified > kernel image which works on HW with/without Svpmbt. > > Better to explore code patching approaches which have zero > overhead. Sure, I think Heiko has some Idea about code patching , and I will wait for his new patches for this mechanism > > Regards, > Anup > > > > > > > > > > +EXPORT_SYMBOL(__svpbmt); > > > > +#endif > > > > > > > > > _______________________________________________ > > linux-riscv mailing list > > linux-riscv@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-riscv > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports 2021-11-29 1:40 ` [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports wefu 2021-11-29 10:48 ` Alexandre Ghiti 2021-11-29 13:36 ` Jisheng Zhang @ 2021-11-30 10:18 ` Guo Ren 2021-12-01 3:03 ` Wei Fu 2021-11-30 18:46 ` Heiko Stübner 3 siblings, 1 reply; 35+ messages in thread From: Guo Ren @ 2021-11-30 10:18 UTC (permalink / raw) To: Wei Fu Cc: Anup Patel, atishp04, Palmer Dabbelt, Christoph Müllner, Philipp Tomsich, Christoph Hellwig, liush, Wei Wu (吴伟), Drew Fustini, linux-riscv, Linux Kernel Mailing List, taiten.peng, Aniket Ponkshe, Heinrich Schuchardt, Gordan Markus, Guo Ren, Arnd Bergmann, Chen-Yu Tsai, Maxime Ripard, Daniel Lustig, Greg Favor, Andrea Mondelli, Jonathan Behrens, Xinhaoqu (Freddie), Bill Huffman, Nick Kossifidis, Allen Baum, Josh Scheid, Richard Trauben, Palmer Dabbelt, Atish Patra Hi, We forgot fixmap, add below into your patch. diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h index 54cbf07fb4e9..899b59bdb9eb 100644 --- a/arch/riscv/include/asm/fixmap.h +++ b/arch/riscv/include/asm/fixmap.h @@ -43,8 +43,6 @@ enum fixed_addresses { __end_of_fixed_addresses }; -#define FIXMAP_PAGE_IO PAGE_KERNEL - #define __early_set_fixmap __set_fixmap #define __late_set_fixmap __set_fixmap diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h index f3c9f9a1c1bb..9bb06384c57f 100644 --- a/arch/riscv/include/asm/pgtable.h +++ b/arch/riscv/include/asm/pgtable.h @@ -126,6 +126,8 @@ | _PAGE_SHARE \ | _PAGE_SO) +#define PAGE_KERNEL_IO __pgprot(_PAGE_IOREMAP) On Mon, Nov 29, 2021 at 9:41 AM <wefu@redhat.com> wrote: > > From: Wei Fu <wefu@redhat.com> > > This patch follows the standard pure RISC-V Svpbmt extension in > privilege spec to solve the non-coherent SOC dma synchronization > issues. > > Here is the svpbmt PTE format: > | 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > N MT RSW D A G U X W R V > ^ > > Of the Reserved bits [63:54] in a leaf PTE, the high bit is already > allocated (as the N bit), so bits [62:61] are used as the MT (aka > MemType) field. This field specifies one of three memory types that > are close equivalents (or equivalent in effect) to the three main x86 > and ARMv8 memory types - as shown in the following table. > > RISC-V > Encoding & > MemType RISC-V Description > ---------- ------------------------------------------------ > 00 - PMA Normal Cacheable, No change to implied PMA memory type > 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory > 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory > 11 - Rsvd Reserved for future standard use > > The standard protection_map[] needn't be modified because the "PMA" > type keeps the highest bits zero. And the whole modification is > limited in the arch/riscv/* and using a global variable > (__svpbmt) as _PAGE_MASK/IO/NOCACHE for pgprot_noncached > (&writecombine) in pgtable.h. We also add _PAGE_CHG_MASK to filter > PFN than before. > > Enable it in devicetree - (Add "riscv,svpbmt" in the mmu of cpu node) > - mmu: > riscv,svpmbt > > Signed-off-by: Wei Fu <wefu@redhat.com> > Co-developed-by: Liu Shaohua <liush@allwinnertech.com> > Signed-off-by: Liu Shaohua <liush@allwinnertech.com> > Co-developed-by: Guo Ren <guoren@kernel.org> > Signed-off-by: Guo Ren <guoren@kernel.org> > Cc: Palmer Dabbelt <palmerdabbelt@google.com> > Cc: Christoph Hellwig <hch@lst.de> > Cc: Anup Patel <anup.patel@wdc.com> > Cc: Arnd Bergmann <arnd@arndb.de> > Cc: Atish Patra <atish.patra@wdc.com> > Cc: Drew Fustini <drew@beagleboard.org> > Cc: Wei Fu <wefu@redhat.com> > Cc: Wei Wu <lazyparser@gmail.com> > Cc: Chen-Yu Tsai <wens@csie.org> > Cc: Maxime Ripard <maxime@cerno.tech> > Cc: Daniel Lustig <dlustig@nvidia.com> > Cc: Greg Favor <gfavor@ventanamicro.com> > Cc: Andrea Mondelli <andrea.mondelli@huawei.com> > Cc: Jonathan Behrens <behrensj@mit.edu> > Cc: Xinhaoqu (Freddie) <xinhaoqu@huawei.com> > Cc: Bill Huffman <huffman@cadence.com> > Cc: Nick Kossifidis <mick@ics.forth.gr> > Cc: Allen Baum <allen.baum@esperantotech.com> > Cc: Josh Scheid <jscheid@ventanamicro.com> > Cc: Richard Trauben <rtrauben@gmail.com> > --- > arch/riscv/include/asm/fixmap.h | 2 +- > arch/riscv/include/asm/pgtable-64.h | 21 ++++++++++++--- > arch/riscv/include/asm/pgtable-bits.h | 39 +++++++++++++++++++++++++-- > arch/riscv/include/asm/pgtable.h | 39 ++++++++++++++++++++------- > arch/riscv/kernel/cpufeature.c | 35 ++++++++++++++++++++++++ > arch/riscv/mm/init.c | 5 ++++ > 6 files changed, 126 insertions(+), 15 deletions(-) > > diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h > index 54cbf07fb4e9..5acd99d08e74 100644 > --- a/arch/riscv/include/asm/fixmap.h > +++ b/arch/riscv/include/asm/fixmap.h > @@ -43,7 +43,7 @@ enum fixed_addresses { > __end_of_fixed_addresses > }; > > -#define FIXMAP_PAGE_IO PAGE_KERNEL > +#define FIXMAP_PAGE_IO PAGE_IOREMAP > > #define __early_set_fixmap __set_fixmap > > diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h > index 228261aa9628..16d251282b1d 100644 > --- a/arch/riscv/include/asm/pgtable-64.h > +++ b/arch/riscv/include/asm/pgtable-64.h > @@ -59,14 +59,29 @@ static inline void pud_clear(pud_t *pudp) > set_pud(pudp, __pud(0)); > } > > +static inline unsigned long _chg_of_pmd(pmd_t pmd) > +{ > + return (pmd_val(pmd) & _PAGE_CHG_MASK); > +} > + > +static inline unsigned long _chg_of_pud(pud_t pud) > +{ > + return (pud_val(pud) & _PAGE_CHG_MASK); > +} > + > +static inline unsigned long _chg_of_pte(pte_t pte) > +{ > + return (pte_val(pte) & _PAGE_CHG_MASK); > +} > + > static inline pmd_t *pud_pgtable(pud_t pud) > { > - return (pmd_t *)pfn_to_virt(pud_val(pud) >> _PAGE_PFN_SHIFT); > + return (pmd_t *)pfn_to_virt(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT); > } > > static inline struct page *pud_page(pud_t pud) > { > - return pfn_to_page(pud_val(pud) >> _PAGE_PFN_SHIFT); > + return pfn_to_page(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT); > } > > static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot) > @@ -76,7 +91,7 @@ static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot) > > static inline unsigned long _pmd_pfn(pmd_t pmd) > { > - return pmd_val(pmd) >> _PAGE_PFN_SHIFT; > + return _chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT; > } > > #define mk_pmd(page, prot) pfn_pmd(page_to_pfn(page), prot) > diff --git a/arch/riscv/include/asm/pgtable-bits.h b/arch/riscv/include/asm/pgtable-bits.h > index 2ee413912926..e5b0fce4ddc5 100644 > --- a/arch/riscv/include/asm/pgtable-bits.h > +++ b/arch/riscv/include/asm/pgtable-bits.h > @@ -7,7 +7,7 @@ > #define _ASM_RISCV_PGTABLE_BITS_H > > /* > - * PTE format: > + * rv32 PTE format: > * | XLEN-1 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > * PFN reserved for SW D A G U X W R V > */ > @@ -24,6 +24,40 @@ > #define _PAGE_DIRTY (1 << 7) /* Set by hardware on any write */ > #define _PAGE_SOFT (1 << 8) /* Reserved for software */ > > +#if !defined(__ASSEMBLY__) && defined(CONFIG_64BIT) > +/* > + * rv64 PTE format: > + * | 63 | 62 61 | 60 54 | 53 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > + * N MT RSV PFN reserved for SW D A G U X W R V > + * [62:61] Memory Type definitions: > + * 00 - PMA Normal Cacheable, No change to implied PMA memory type > + * 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory > + * 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory > + * 11 - Rsvd Reserved for future standard use > + */ > +#define _SVPBMT_PMA 0UL > +#define _SVPBMT_NC (1UL << 61) > +#define _SVPBMT_IO (1UL << 62) > +#define _SVPBMT_MASK (_SVPBMT_NC | _SVPBMT_IO) > + > +extern struct __svpbmt_struct { > + unsigned long mask; > + unsigned long pma; > + unsigned long nocache; > + unsigned long io; > +} __svpbmt __cacheline_aligned; > + > +#define _PAGE_MASK __svpbmt.mask > +#define _PAGE_PMA __svpbmt.pma > +#define _PAGE_NOCACHE __svpbmt.nocache > +#define _PAGE_IO __svpbmt.io > +#else > +#define _PAGE_MASK 0 > +#define _PAGE_PMA 0 > +#define _PAGE_NOCACHE 0 > +#define _PAGE_IO 0 > +#endif /* !__ASSEMBLY__ && CONFIG_64BIT */ > + > #define _PAGE_SPECIAL _PAGE_SOFT > #define _PAGE_TABLE _PAGE_PRESENT > > @@ -38,7 +72,8 @@ > /* Set of bits to preserve across pte_modify() */ > #define _PAGE_CHG_MASK (~(unsigned long)(_PAGE_PRESENT | _PAGE_READ | \ > _PAGE_WRITE | _PAGE_EXEC | \ > - _PAGE_USER | _PAGE_GLOBAL)) > + _PAGE_USER | _PAGE_GLOBAL | \ > + _PAGE_MASK)) > /* > * when all of R/W/X are zero, the PTE is a pointer to the next level > * of the page table; otherwise, it is a leaf PTE. > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h > index bf204e7c1f74..0f7a6541015f 100644 > --- a/arch/riscv/include/asm/pgtable.h > +++ b/arch/riscv/include/asm/pgtable.h > @@ -138,7 +138,8 @@ > | _PAGE_PRESENT \ > | _PAGE_ACCESSED \ > | _PAGE_DIRTY \ > - | _PAGE_GLOBAL) > + | _PAGE_GLOBAL \ > + | _PAGE_PMA) > > #define PAGE_KERNEL __pgprot(_PAGE_KERNEL) > #define PAGE_KERNEL_READ __pgprot(_PAGE_KERNEL & ~_PAGE_WRITE) > @@ -148,11 +149,9 @@ > > #define PAGE_TABLE __pgprot(_PAGE_TABLE) > > -/* > - * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't > - * change the properties of memory regions. > - */ > -#define _PAGE_IOREMAP _PAGE_KERNEL > +#define _PAGE_IOREMAP ((_PAGE_KERNEL & ~_PAGE_MASK) | _PAGE_IO) > + > +#define PAGE_IOREMAP __pgprot(_PAGE_IOREMAP) > > extern pgd_t swapper_pg_dir[]; > > @@ -232,12 +231,12 @@ static inline unsigned long _pgd_pfn(pgd_t pgd) > > static inline struct page *pmd_page(pmd_t pmd) > { > - return pfn_to_page(pmd_val(pmd) >> _PAGE_PFN_SHIFT); > + return pfn_to_page(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT); > } > > static inline unsigned long pmd_page_vaddr(pmd_t pmd) > { > - return (unsigned long)pfn_to_virt(pmd_val(pmd) >> _PAGE_PFN_SHIFT); > + return (unsigned long)pfn_to_virt(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT); > } > > static inline pte_t pmd_pte(pmd_t pmd) > @@ -253,7 +252,7 @@ static inline pte_t pud_pte(pud_t pud) > /* Yields the page frame number (PFN) of a page table entry */ > static inline unsigned long pte_pfn(pte_t pte) > { > - return (pte_val(pte) >> _PAGE_PFN_SHIFT); > + return (_chg_of_pte(pte) >> _PAGE_PFN_SHIFT); > } > > #define pte_page(x) pfn_to_page(pte_pfn(x)) > @@ -492,6 +491,28 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma, > return ptep_test_and_clear_young(vma, address, ptep); > } > > +#define pgprot_noncached pgprot_noncached > +static inline pgprot_t pgprot_noncached(pgprot_t _prot) > +{ > + unsigned long prot = pgprot_val(_prot); > + > + prot &= ~_PAGE_MASK; > + prot |= _PAGE_IO; > + > + return __pgprot(prot); > +} > + > +#define pgprot_writecombine pgprot_writecombine > +static inline pgprot_t pgprot_writecombine(pgprot_t _prot) > +{ > + unsigned long prot = pgprot_val(_prot); > + > + prot &= ~_PAGE_MASK; > + prot |= _PAGE_NOCACHE; > + > + return __pgprot(prot); > +} > + > /* > * THP functions > */ > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c > index d959d207a40d..fa7480cb8b87 100644 > --- a/arch/riscv/kernel/cpufeature.c > +++ b/arch/riscv/kernel/cpufeature.c > @@ -8,6 +8,7 @@ > > #include <linux/bitmap.h> > #include <linux/of.h> > +#include <linux/pgtable.h> > #include <asm/processor.h> > #include <asm/hwcap.h> > #include <asm/smp.h> > @@ -59,6 +60,38 @@ bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit) > } > EXPORT_SYMBOL_GPL(__riscv_isa_extension_available); > > +static void __init mmu_supports_svpbmt(void) > +{ > +#if defined(CONFIG_MMU) && defined(CONFIG_64BIT) > + struct device_node *node; > + const char *str; > + > + for_each_of_cpu_node(node) { > + if (of_property_read_string(node, "mmu-type", &str)) > + continue; > + > + if (!strncmp(str + 6, "none", 4)) > + continue; > + > + if (of_property_read_string(node, "mmu", &str)) > + continue; > + > + if (strncmp(str + 6, "svpmbt", 6)) > + continue; > + } > + > + __svpbmt.pma = _SVPBMT_PMA; > + __svpbmt.nocache = _SVPBMT_NC; > + __svpbmt.io = _SVPBMT_IO; > + __svpbmt.mask = _SVPBMT_MASK; > +#endif > +} > + > +static void __init mmu_supports(void) > +{ > + mmu_supports_svpbmt(); > +} > + > void __init riscv_fill_hwcap(void) > { > struct device_node *node; > @@ -67,6 +100,8 @@ void __init riscv_fill_hwcap(void) > size_t i, j, isa_len; > static unsigned long isa2hwcap[256] = {0}; > > + mmu_supports(); > + > isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I; > isa2hwcap['m'] = isa2hwcap['M'] = COMPAT_HWCAP_ISA_M; > isa2hwcap['a'] = isa2hwcap['A'] = COMPAT_HWCAP_ISA_A; > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c > index 24b2b8044602..e4e658165ee1 100644 > --- a/arch/riscv/mm/init.c > +++ b/arch/riscv/mm/init.c > @@ -854,3 +854,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, > return vmemmap_populate_basepages(start, end, node, NULL); > } > #endif > + > +#if defined(CONFIG_64BIT) > +struct __svpbmt_struct __svpbmt __ro_after_init; > +EXPORT_SYMBOL(__svpbmt); > +#endif > -- > 2.25.4 > -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/ ^ permalink raw reply related [flat|nested] 35+ messages in thread
* Re: [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports 2021-11-30 10:18 ` Guo Ren @ 2021-12-01 3:03 ` Wei Fu 0 siblings, 0 replies; 35+ messages in thread From: Wei Fu @ 2021-12-01 3:03 UTC (permalink / raw) To: Guo Ren Cc: Anup Patel, atishp04, Palmer Dabbelt, Christoph Müllner, Philipp Tomsich, Christoph Hellwig, liush, Wei Wu (吴伟), Drew Fustini, linux-riscv, Linux Kernel Mailing List, taiten.peng, Aniket Ponkshe, Heinrich Schuchardt, Gordan Markus, Guo Ren, Arnd Bergmann, Chen-Yu Tsai, Maxime Ripard, Daniel Lustig, Greg Favor, Andrea Mondelli, Jonathan Behrens, Xinhaoqu (Freddie), Bill Huffman, Nick Kossifidis, Allen Baum, Josh Scheid, Richard Trauben, Palmer Dabbelt, Atish Patra Thanks for reminding me, Guo Ren. :-) yes, I am working on the new version , yes, my bad, I am adding it in to my V5 On Tue, Nov 30, 2021 at 6:19 PM Guo Ren <guoren@kernel.org> wrote: > > Hi, > > We forgot fixmap, add below into your patch. > > diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h > index 54cbf07fb4e9..899b59bdb9eb 100644 > --- a/arch/riscv/include/asm/fixmap.h > +++ b/arch/riscv/include/asm/fixmap.h > @@ -43,8 +43,6 @@ enum fixed_addresses { > __end_of_fixed_addresses > }; > > -#define FIXMAP_PAGE_IO PAGE_KERNEL > - > #define __early_set_fixmap __set_fixmap > > #define __late_set_fixmap __set_fixmap > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h > index f3c9f9a1c1bb..9bb06384c57f 100644 > --- a/arch/riscv/include/asm/pgtable.h > +++ b/arch/riscv/include/asm/pgtable.h > @@ -126,6 +126,8 @@ > | _PAGE_SHARE \ > | _PAGE_SO) > > +#define PAGE_KERNEL_IO __pgprot(_PAGE_IOREMAP) > > On Mon, Nov 29, 2021 at 9:41 AM <wefu@redhat.com> wrote: > > > > From: Wei Fu <wefu@redhat.com> > > > > This patch follows the standard pure RISC-V Svpbmt extension in > > privilege spec to solve the non-coherent SOC dma synchronization > > issues. > > > > Here is the svpbmt PTE format: > > | 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > > N MT RSW D A G U X W R V > > ^ > > > > Of the Reserved bits [63:54] in a leaf PTE, the high bit is already > > allocated (as the N bit), so bits [62:61] are used as the MT (aka > > MemType) field. This field specifies one of three memory types that > > are close equivalents (or equivalent in effect) to the three main x86 > > and ARMv8 memory types - as shown in the following table. > > > > RISC-V > > Encoding & > > MemType RISC-V Description > > ---------- ------------------------------------------------ > > 00 - PMA Normal Cacheable, No change to implied PMA memory type > > 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory > > 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory > > 11 - Rsvd Reserved for future standard use > > > > The standard protection_map[] needn't be modified because the "PMA" > > type keeps the highest bits zero. And the whole modification is > > limited in the arch/riscv/* and using a global variable > > (__svpbmt) as _PAGE_MASK/IO/NOCACHE for pgprot_noncached > > (&writecombine) in pgtable.h. We also add _PAGE_CHG_MASK to filter > > PFN than before. > > > > Enable it in devicetree - (Add "riscv,svpbmt" in the mmu of cpu node) > > - mmu: > > riscv,svpmbt > > > > Signed-off-by: Wei Fu <wefu@redhat.com> > > Co-developed-by: Liu Shaohua <liush@allwinnertech.com> > > Signed-off-by: Liu Shaohua <liush@allwinnertech.com> > > Co-developed-by: Guo Ren <guoren@kernel.org> > > Signed-off-by: Guo Ren <guoren@kernel.org> > > Cc: Palmer Dabbelt <palmerdabbelt@google.com> > > Cc: Christoph Hellwig <hch@lst.de> > > Cc: Anup Patel <anup.patel@wdc.com> > > Cc: Arnd Bergmann <arnd@arndb.de> > > Cc: Atish Patra <atish.patra@wdc.com> > > Cc: Drew Fustini <drew@beagleboard.org> > > Cc: Wei Fu <wefu@redhat.com> > > Cc: Wei Wu <lazyparser@gmail.com> > > Cc: Chen-Yu Tsai <wens@csie.org> > > Cc: Maxime Ripard <maxime@cerno.tech> > > Cc: Daniel Lustig <dlustig@nvidia.com> > > Cc: Greg Favor <gfavor@ventanamicro.com> > > Cc: Andrea Mondelli <andrea.mondelli@huawei.com> > > Cc: Jonathan Behrens <behrensj@mit.edu> > > Cc: Xinhaoqu (Freddie) <xinhaoqu@huawei.com> > > Cc: Bill Huffman <huffman@cadence.com> > > Cc: Nick Kossifidis <mick@ics.forth.gr> > > Cc: Allen Baum <allen.baum@esperantotech.com> > > Cc: Josh Scheid <jscheid@ventanamicro.com> > > Cc: Richard Trauben <rtrauben@gmail.com> > > --- > > arch/riscv/include/asm/fixmap.h | 2 +- > > arch/riscv/include/asm/pgtable-64.h | 21 ++++++++++++--- > > arch/riscv/include/asm/pgtable-bits.h | 39 +++++++++++++++++++++++++-- > > arch/riscv/include/asm/pgtable.h | 39 ++++++++++++++++++++------- > > arch/riscv/kernel/cpufeature.c | 35 ++++++++++++++++++++++++ > > arch/riscv/mm/init.c | 5 ++++ > > 6 files changed, 126 insertions(+), 15 deletions(-) > > > > diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h > > index 54cbf07fb4e9..5acd99d08e74 100644 > > --- a/arch/riscv/include/asm/fixmap.h > > +++ b/arch/riscv/include/asm/fixmap.h > > @@ -43,7 +43,7 @@ enum fixed_addresses { > > __end_of_fixed_addresses > > }; > > > > -#define FIXMAP_PAGE_IO PAGE_KERNEL > > +#define FIXMAP_PAGE_IO PAGE_IOREMAP > > > > #define __early_set_fixmap __set_fixmap > > > > diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h > > index 228261aa9628..16d251282b1d 100644 > > --- a/arch/riscv/include/asm/pgtable-64.h > > +++ b/arch/riscv/include/asm/pgtable-64.h > > @@ -59,14 +59,29 @@ static inline void pud_clear(pud_t *pudp) > > set_pud(pudp, __pud(0)); > > } > > > > +static inline unsigned long _chg_of_pmd(pmd_t pmd) > > +{ > > + return (pmd_val(pmd) & _PAGE_CHG_MASK); > > +} > > + > > +static inline unsigned long _chg_of_pud(pud_t pud) > > +{ > > + return (pud_val(pud) & _PAGE_CHG_MASK); > > +} > > + > > +static inline unsigned long _chg_of_pte(pte_t pte) > > +{ > > + return (pte_val(pte) & _PAGE_CHG_MASK); > > +} > > + > > static inline pmd_t *pud_pgtable(pud_t pud) > > { > > - return (pmd_t *)pfn_to_virt(pud_val(pud) >> _PAGE_PFN_SHIFT); > > + return (pmd_t *)pfn_to_virt(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT); > > } > > > > static inline struct page *pud_page(pud_t pud) > > { > > - return pfn_to_page(pud_val(pud) >> _PAGE_PFN_SHIFT); > > + return pfn_to_page(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT); > > } > > > > static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot) > > @@ -76,7 +91,7 @@ static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot) > > > > static inline unsigned long _pmd_pfn(pmd_t pmd) > > { > > - return pmd_val(pmd) >> _PAGE_PFN_SHIFT; > > + return _chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT; > > } > > > > #define mk_pmd(page, prot) pfn_pmd(page_to_pfn(page), prot) > > diff --git a/arch/riscv/include/asm/pgtable-bits.h b/arch/riscv/include/asm/pgtable-bits.h > > index 2ee413912926..e5b0fce4ddc5 100644 > > --- a/arch/riscv/include/asm/pgtable-bits.h > > +++ b/arch/riscv/include/asm/pgtable-bits.h > > @@ -7,7 +7,7 @@ > > #define _ASM_RISCV_PGTABLE_BITS_H > > > > /* > > - * PTE format: > > + * rv32 PTE format: > > * | XLEN-1 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > > * PFN reserved for SW D A G U X W R V > > */ > > @@ -24,6 +24,40 @@ > > #define _PAGE_DIRTY (1 << 7) /* Set by hardware on any write */ > > #define _PAGE_SOFT (1 << 8) /* Reserved for software */ > > > > +#if !defined(__ASSEMBLY__) && defined(CONFIG_64BIT) > > +/* > > + * rv64 PTE format: > > + * | 63 | 62 61 | 60 54 | 53 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > > + * N MT RSV PFN reserved for SW D A G U X W R V > > + * [62:61] Memory Type definitions: > > + * 00 - PMA Normal Cacheable, No change to implied PMA memory type > > + * 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory > > + * 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory > > + * 11 - Rsvd Reserved for future standard use > > + */ > > +#define _SVPBMT_PMA 0UL > > +#define _SVPBMT_NC (1UL << 61) > > +#define _SVPBMT_IO (1UL << 62) > > +#define _SVPBMT_MASK (_SVPBMT_NC | _SVPBMT_IO) > > + > > +extern struct __svpbmt_struct { > > + unsigned long mask; > > + unsigned long pma; > > + unsigned long nocache; > > + unsigned long io; > > +} __svpbmt __cacheline_aligned; > > + > > +#define _PAGE_MASK __svpbmt.mask > > +#define _PAGE_PMA __svpbmt.pma > > +#define _PAGE_NOCACHE __svpbmt.nocache > > +#define _PAGE_IO __svpbmt.io > > +#else > > +#define _PAGE_MASK 0 > > +#define _PAGE_PMA 0 > > +#define _PAGE_NOCACHE 0 > > +#define _PAGE_IO 0 > > +#endif /* !__ASSEMBLY__ && CONFIG_64BIT */ > > + > > #define _PAGE_SPECIAL _PAGE_SOFT > > #define _PAGE_TABLE _PAGE_PRESENT > > > > @@ -38,7 +72,8 @@ > > /* Set of bits to preserve across pte_modify() */ > > #define _PAGE_CHG_MASK (~(unsigned long)(_PAGE_PRESENT | _PAGE_READ | \ > > _PAGE_WRITE | _PAGE_EXEC | \ > > - _PAGE_USER | _PAGE_GLOBAL)) > > + _PAGE_USER | _PAGE_GLOBAL | \ > > + _PAGE_MASK)) > > /* > > * when all of R/W/X are zero, the PTE is a pointer to the next level > > * of the page table; otherwise, it is a leaf PTE. > > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h > > index bf204e7c1f74..0f7a6541015f 100644 > > --- a/arch/riscv/include/asm/pgtable.h > > +++ b/arch/riscv/include/asm/pgtable.h > > @@ -138,7 +138,8 @@ > > | _PAGE_PRESENT \ > > | _PAGE_ACCESSED \ > > | _PAGE_DIRTY \ > > - | _PAGE_GLOBAL) > > + | _PAGE_GLOBAL \ > > + | _PAGE_PMA) > > > > #define PAGE_KERNEL __pgprot(_PAGE_KERNEL) > > #define PAGE_KERNEL_READ __pgprot(_PAGE_KERNEL & ~_PAGE_WRITE) > > @@ -148,11 +149,9 @@ > > > > #define PAGE_TABLE __pgprot(_PAGE_TABLE) > > > > -/* > > - * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't > > - * change the properties of memory regions. > > - */ > > -#define _PAGE_IOREMAP _PAGE_KERNEL > > +#define _PAGE_IOREMAP ((_PAGE_KERNEL & ~_PAGE_MASK) | _PAGE_IO) > > + > > +#define PAGE_IOREMAP __pgprot(_PAGE_IOREMAP) > > > > extern pgd_t swapper_pg_dir[]; > > > > @@ -232,12 +231,12 @@ static inline unsigned long _pgd_pfn(pgd_t pgd) > > > > static inline struct page *pmd_page(pmd_t pmd) > > { > > - return pfn_to_page(pmd_val(pmd) >> _PAGE_PFN_SHIFT); > > + return pfn_to_page(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT); > > } > > > > static inline unsigned long pmd_page_vaddr(pmd_t pmd) > > { > > - return (unsigned long)pfn_to_virt(pmd_val(pmd) >> _PAGE_PFN_SHIFT); > > + return (unsigned long)pfn_to_virt(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT); > > } > > > > static inline pte_t pmd_pte(pmd_t pmd) > > @@ -253,7 +252,7 @@ static inline pte_t pud_pte(pud_t pud) > > /* Yields the page frame number (PFN) of a page table entry */ > > static inline unsigned long pte_pfn(pte_t pte) > > { > > - return (pte_val(pte) >> _PAGE_PFN_SHIFT); > > + return (_chg_of_pte(pte) >> _PAGE_PFN_SHIFT); > > } > > > > #define pte_page(x) pfn_to_page(pte_pfn(x)) > > @@ -492,6 +491,28 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma, > > return ptep_test_and_clear_young(vma, address, ptep); > > } > > > > +#define pgprot_noncached pgprot_noncached > > +static inline pgprot_t pgprot_noncached(pgprot_t _prot) > > +{ > > + unsigned long prot = pgprot_val(_prot); > > + > > + prot &= ~_PAGE_MASK; > > + prot |= _PAGE_IO; > > + > > + return __pgprot(prot); > > +} > > + > > +#define pgprot_writecombine pgprot_writecombine > > +static inline pgprot_t pgprot_writecombine(pgprot_t _prot) > > +{ > > + unsigned long prot = pgprot_val(_prot); > > + > > + prot &= ~_PAGE_MASK; > > + prot |= _PAGE_NOCACHE; > > + > > + return __pgprot(prot); > > +} > > + > > /* > > * THP functions > > */ > > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c > > index d959d207a40d..fa7480cb8b87 100644 > > --- a/arch/riscv/kernel/cpufeature.c > > +++ b/arch/riscv/kernel/cpufeature.c > > @@ -8,6 +8,7 @@ > > > > #include <linux/bitmap.h> > > #include <linux/of.h> > > +#include <linux/pgtable.h> > > #include <asm/processor.h> > > #include <asm/hwcap.h> > > #include <asm/smp.h> > > @@ -59,6 +60,38 @@ bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit) > > } > > EXPORT_SYMBOL_GPL(__riscv_isa_extension_available); > > > > +static void __init mmu_supports_svpbmt(void) > > +{ > > +#if defined(CONFIG_MMU) && defined(CONFIG_64BIT) > > + struct device_node *node; > > + const char *str; > > + > > + for_each_of_cpu_node(node) { > > + if (of_property_read_string(node, "mmu-type", &str)) > > + continue; > > + > > + if (!strncmp(str + 6, "none", 4)) > > + continue; > > + > > + if (of_property_read_string(node, "mmu", &str)) > > + continue; > > + > > + if (strncmp(str + 6, "svpmbt", 6)) > > + continue; > > + } > > + > > + __svpbmt.pma = _SVPBMT_PMA; > > + __svpbmt.nocache = _SVPBMT_NC; > > + __svpbmt.io = _SVPBMT_IO; > > + __svpbmt.mask = _SVPBMT_MASK; > > +#endif > > +} > > + > > +static void __init mmu_supports(void) > > +{ > > + mmu_supports_svpbmt(); > > +} > > + > > void __init riscv_fill_hwcap(void) > > { > > struct device_node *node; > > @@ -67,6 +100,8 @@ void __init riscv_fill_hwcap(void) > > size_t i, j, isa_len; > > static unsigned long isa2hwcap[256] = {0}; > > > > + mmu_supports(); > > + > > isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I; > > isa2hwcap['m'] = isa2hwcap['M'] = COMPAT_HWCAP_ISA_M; > > isa2hwcap['a'] = isa2hwcap['A'] = COMPAT_HWCAP_ISA_A; > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c > > index 24b2b8044602..e4e658165ee1 100644 > > --- a/arch/riscv/mm/init.c > > +++ b/arch/riscv/mm/init.c > > @@ -854,3 +854,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, > > return vmemmap_populate_basepages(start, end, node, NULL); > > } > > #endif > > + > > +#if defined(CONFIG_64BIT) > > +struct __svpbmt_struct __svpbmt __ro_after_init; > > +EXPORT_SYMBOL(__svpbmt); > > +#endif > > -- > > 2.25.4 > > > > > -- > Best Regards > Guo Ren > > ML: https://lore.kernel.org/linux-csky/ > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports 2021-11-29 1:40 ` [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports wefu ` (2 preceding siblings ...) 2021-11-30 10:18 ` Guo Ren @ 2021-11-30 18:46 ` Heiko Stübner 2021-12-01 3:00 ` Wei Fu 3 siblings, 1 reply; 35+ messages in thread From: Heiko Stübner @ 2021-11-30 18:46 UTC (permalink / raw) To: anup.patel, atishp04, palmer, guoren, christoph.muellner, philipp.tomsich, hch, liush, wefu, lazyparser, drew, linux-riscv Cc: linux-riscv, linux-kernel, taiten.peng, aniket.ponkshe, heinrich.schuchardt, gordan.markus, guoren, arnd, wens, maxime, dlustig, gfavor, andrea.mondelli, behrensj, xinhaoqu, huffman, mick, allen.baum, jscheid, rtrauben, Palmer Dabbelt, Atish Patra, wefu Am Montag, 29. November 2021, 02:40:07 CET schrieb wefu@redhat.com: > From: Wei Fu <wefu@redhat.com> > > This patch follows the standard pure RISC-V Svpbmt extension in > privilege spec to solve the non-coherent SOC dma synchronization > issues. > > Here is the svpbmt PTE format: > | 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > N MT RSW D A G U X W R V > ^ > > Of the Reserved bits [63:54] in a leaf PTE, the high bit is already > allocated (as the N bit), so bits [62:61] are used as the MT (aka > MemType) field. This field specifies one of three memory types that > are close equivalents (or equivalent in effect) to the three main x86 > and ARMv8 memory types - as shown in the following table. > > RISC-V > Encoding & > MemType RISC-V Description > ---------- ------------------------------------------------ > 00 - PMA Normal Cacheable, No change to implied PMA memory type > 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory > 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory > 11 - Rsvd Reserved for future standard use > > The standard protection_map[] needn't be modified because the "PMA" > type keeps the highest bits zero. And the whole modification is > limited in the arch/riscv/* and using a global variable > (__svpbmt) as _PAGE_MASK/IO/NOCACHE for pgprot_noncached > (&writecombine) in pgtable.h. We also add _PAGE_CHG_MASK to filter > PFN than before. > > Enable it in devicetree - (Add "riscv,svpbmt" in the mmu of cpu node) > - mmu: > riscv,svpmbt > > Signed-off-by: Wei Fu <wefu@redhat.com> > Co-developed-by: Liu Shaohua <liush@allwinnertech.com> > Signed-off-by: Liu Shaohua <liush@allwinnertech.com> > Co-developed-by: Guo Ren <guoren@kernel.org> > Signed-off-by: Guo Ren <guoren@kernel.org> > Cc: Palmer Dabbelt <palmerdabbelt@google.com> > Cc: Christoph Hellwig <hch@lst.de> > Cc: Anup Patel <anup.patel@wdc.com> > Cc: Arnd Bergmann <arnd@arndb.de> > Cc: Atish Patra <atish.patra@wdc.com> > Cc: Drew Fustini <drew@beagleboard.org> > Cc: Wei Fu <wefu@redhat.com> > Cc: Wei Wu <lazyparser@gmail.com> > Cc: Chen-Yu Tsai <wens@csie.org> > Cc: Maxime Ripard <maxime@cerno.tech> > Cc: Daniel Lustig <dlustig@nvidia.com> > Cc: Greg Favor <gfavor@ventanamicro.com> > Cc: Andrea Mondelli <andrea.mondelli@huawei.com> > Cc: Jonathan Behrens <behrensj@mit.edu> > Cc: Xinhaoqu (Freddie) <xinhaoqu@huawei.com> > Cc: Bill Huffman <huffman@cadence.com> > Cc: Nick Kossifidis <mick@ics.forth.gr> > Cc: Allen Baum <allen.baum@esperantotech.com> > Cc: Josh Scheid <jscheid@ventanamicro.com> > Cc: Richard Trauben <rtrauben@gmail.com> > --- > arch/riscv/include/asm/fixmap.h | 2 +- > arch/riscv/include/asm/pgtable-64.h | 21 ++++++++++++--- > arch/riscv/include/asm/pgtable-bits.h | 39 +++++++++++++++++++++++++-- > arch/riscv/include/asm/pgtable.h | 39 ++++++++++++++++++++------- > arch/riscv/kernel/cpufeature.c | 35 ++++++++++++++++++++++++ > arch/riscv/mm/init.c | 5 ++++ > 6 files changed, 126 insertions(+), 15 deletions(-) > > diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h > index 54cbf07fb4e9..5acd99d08e74 100644 > --- a/arch/riscv/include/asm/fixmap.h > +++ b/arch/riscv/include/asm/fixmap.h > @@ -43,7 +43,7 @@ enum fixed_addresses { > __end_of_fixed_addresses > }; > > -#define FIXMAP_PAGE_IO PAGE_KERNEL > +#define FIXMAP_PAGE_IO PAGE_IOREMAP > > #define __early_set_fixmap __set_fixmap > > diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h > index 228261aa9628..16d251282b1d 100644 > --- a/arch/riscv/include/asm/pgtable-64.h > +++ b/arch/riscv/include/asm/pgtable-64.h > @@ -59,14 +59,29 @@ static inline void pud_clear(pud_t *pudp) > set_pud(pudp, __pud(0)); > } > > +static inline unsigned long _chg_of_pmd(pmd_t pmd) > +{ > + return (pmd_val(pmd) & _PAGE_CHG_MASK); > +} > + > +static inline unsigned long _chg_of_pud(pud_t pud) > +{ > + return (pud_val(pud) & _PAGE_CHG_MASK); > +} > + > +static inline unsigned long _chg_of_pte(pte_t pte) > +{ > + return (pte_val(pte) & _PAGE_CHG_MASK); > +} > + > static inline pmd_t *pud_pgtable(pud_t pud) > { > - return (pmd_t *)pfn_to_virt(pud_val(pud) >> _PAGE_PFN_SHIFT); > + return (pmd_t *)pfn_to_virt(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT); > } > > static inline struct page *pud_page(pud_t pud) > { > - return pfn_to_page(pud_val(pud) >> _PAGE_PFN_SHIFT); > + return pfn_to_page(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT); > } > > static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot) > @@ -76,7 +91,7 @@ static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot) > > static inline unsigned long _pmd_pfn(pmd_t pmd) > { > - return pmd_val(pmd) >> _PAGE_PFN_SHIFT; > + return _chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT; > } > > #define mk_pmd(page, prot) pfn_pmd(page_to_pfn(page), prot) > diff --git a/arch/riscv/include/asm/pgtable-bits.h b/arch/riscv/include/asm/pgtable-bits.h > index 2ee413912926..e5b0fce4ddc5 100644 > --- a/arch/riscv/include/asm/pgtable-bits.h > +++ b/arch/riscv/include/asm/pgtable-bits.h > @@ -7,7 +7,7 @@ > #define _ASM_RISCV_PGTABLE_BITS_H > > /* > - * PTE format: > + * rv32 PTE format: > * | XLEN-1 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > * PFN reserved for SW D A G U X W R V > */ > @@ -24,6 +24,40 @@ > #define _PAGE_DIRTY (1 << 7) /* Set by hardware on any write */ > #define _PAGE_SOFT (1 << 8) /* Reserved for software */ > > +#if !defined(__ASSEMBLY__) && defined(CONFIG_64BIT) > +/* > + * rv64 PTE format: > + * | 63 | 62 61 | 60 54 | 53 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > + * N MT RSV PFN reserved for SW D A G U X W R V > + * [62:61] Memory Type definitions: > + * 00 - PMA Normal Cacheable, No change to implied PMA memory type > + * 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory > + * 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory > + * 11 - Rsvd Reserved for future standard use > + */ > +#define _SVPBMT_PMA 0UL > +#define _SVPBMT_NC (1UL << 61) > +#define _SVPBMT_IO (1UL << 62) > +#define _SVPBMT_MASK (_SVPBMT_NC | _SVPBMT_IO) > + > +extern struct __svpbmt_struct { > + unsigned long mask; > + unsigned long pma; > + unsigned long nocache; > + unsigned long io; > +} __svpbmt __cacheline_aligned; > + > +#define _PAGE_MASK __svpbmt.mask > +#define _PAGE_PMA __svpbmt.pma > +#define _PAGE_NOCACHE __svpbmt.nocache > +#define _PAGE_IO __svpbmt.io > +#else > +#define _PAGE_MASK 0 > +#define _PAGE_PMA 0 > +#define _PAGE_NOCACHE 0 > +#define _PAGE_IO 0 > +#endif /* !__ASSEMBLY__ && CONFIG_64BIT */ > + > #define _PAGE_SPECIAL _PAGE_SOFT > #define _PAGE_TABLE _PAGE_PRESENT > > @@ -38,7 +72,8 @@ > /* Set of bits to preserve across pte_modify() */ > #define _PAGE_CHG_MASK (~(unsigned long)(_PAGE_PRESENT | _PAGE_READ | \ > _PAGE_WRITE | _PAGE_EXEC | \ > - _PAGE_USER | _PAGE_GLOBAL)) > + _PAGE_USER | _PAGE_GLOBAL | \ > + _PAGE_MASK)) > /* > * when all of R/W/X are zero, the PTE is a pointer to the next level > * of the page table; otherwise, it is a leaf PTE. > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h > index bf204e7c1f74..0f7a6541015f 100644 > --- a/arch/riscv/include/asm/pgtable.h > +++ b/arch/riscv/include/asm/pgtable.h > @@ -138,7 +138,8 @@ > | _PAGE_PRESENT \ > | _PAGE_ACCESSED \ > | _PAGE_DIRTY \ > - | _PAGE_GLOBAL) > + | _PAGE_GLOBAL \ > + | _PAGE_PMA) > > #define PAGE_KERNEL __pgprot(_PAGE_KERNEL) > #define PAGE_KERNEL_READ __pgprot(_PAGE_KERNEL & ~_PAGE_WRITE) > @@ -148,11 +149,9 @@ > > #define PAGE_TABLE __pgprot(_PAGE_TABLE) > > -/* > - * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't > - * change the properties of memory regions. > - */ > -#define _PAGE_IOREMAP _PAGE_KERNEL > +#define _PAGE_IOREMAP ((_PAGE_KERNEL & ~_PAGE_MASK) | _PAGE_IO) > + > +#define PAGE_IOREMAP __pgprot(_PAGE_IOREMAP) > > extern pgd_t swapper_pg_dir[]; > > @@ -232,12 +231,12 @@ static inline unsigned long _pgd_pfn(pgd_t pgd) > > static inline struct page *pmd_page(pmd_t pmd) > { > - return pfn_to_page(pmd_val(pmd) >> _PAGE_PFN_SHIFT); > + return pfn_to_page(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT); > } > > static inline unsigned long pmd_page_vaddr(pmd_t pmd) > { > - return (unsigned long)pfn_to_virt(pmd_val(pmd) >> _PAGE_PFN_SHIFT); > + return (unsigned long)pfn_to_virt(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT); > } > > static inline pte_t pmd_pte(pmd_t pmd) > @@ -253,7 +252,7 @@ static inline pte_t pud_pte(pud_t pud) > /* Yields the page frame number (PFN) of a page table entry */ > static inline unsigned long pte_pfn(pte_t pte) > { > - return (pte_val(pte) >> _PAGE_PFN_SHIFT); > + return (_chg_of_pte(pte) >> _PAGE_PFN_SHIFT); > } > > #define pte_page(x) pfn_to_page(pte_pfn(x)) > @@ -492,6 +491,28 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma, > return ptep_test_and_clear_young(vma, address, ptep); > } > > +#define pgprot_noncached pgprot_noncached > +static inline pgprot_t pgprot_noncached(pgprot_t _prot) > +{ > + unsigned long prot = pgprot_val(_prot); > + > + prot &= ~_PAGE_MASK; > + prot |= _PAGE_IO; > + > + return __pgprot(prot); > +} > + > +#define pgprot_writecombine pgprot_writecombine > +static inline pgprot_t pgprot_writecombine(pgprot_t _prot) > +{ > + unsigned long prot = pgprot_val(_prot); > + > + prot &= ~_PAGE_MASK; > + prot |= _PAGE_NOCACHE; > + > + return __pgprot(prot); > +} > + > /* > * THP functions > */ > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c > index d959d207a40d..fa7480cb8b87 100644 > --- a/arch/riscv/kernel/cpufeature.c > +++ b/arch/riscv/kernel/cpufeature.c > @@ -8,6 +8,7 @@ > > #include <linux/bitmap.h> > #include <linux/of.h> > +#include <linux/pgtable.h> > #include <asm/processor.h> > #include <asm/hwcap.h> > #include <asm/smp.h> > @@ -59,6 +60,38 @@ bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit) > } > EXPORT_SYMBOL_GPL(__riscv_isa_extension_available); > > +static void __init mmu_supports_svpbmt(void) > +{ > +#if defined(CONFIG_MMU) && defined(CONFIG_64BIT) > + struct device_node *node; > + const char *str; > + > + for_each_of_cpu_node(node) { > + if (of_property_read_string(node, "mmu-type", &str)) > + continue; > + > + if (!strncmp(str + 6, "none", 4)) > + continue; > + > + if (of_property_read_string(node, "mmu", &str)) > + continue; > + > + if (strncmp(str + 6, "svpmbt", 6)) same here ... check for "svpbmt" [m seems to be at the wrong position] > + continue; > + } > + > + __svpbmt.pma = _SVPBMT_PMA; > + __svpbmt.nocache = _SVPBMT_NC; > + __svpbmt.io = _SVPBMT_IO; > + __svpbmt.mask = _SVPBMT_MASK; > +#endif > +} > + > +static void __init mmu_supports(void) > +{ > + mmu_supports_svpbmt(); > +} > + > void __init riscv_fill_hwcap(void) > { > struct device_node *node; > @@ -67,6 +100,8 @@ void __init riscv_fill_hwcap(void) > size_t i, j, isa_len; > static unsigned long isa2hwcap[256] = {0}; > > + mmu_supports(); > + > isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I; > isa2hwcap['m'] = isa2hwcap['M'] = COMPAT_HWCAP_ISA_M; > isa2hwcap['a'] = isa2hwcap['A'] = COMPAT_HWCAP_ISA_A; > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c > index 24b2b8044602..e4e658165ee1 100644 > --- a/arch/riscv/mm/init.c > +++ b/arch/riscv/mm/init.c > @@ -854,3 +854,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, > return vmemmap_populate_basepages(start, end, node, NULL); > } > #endif > + > +#if defined(CONFIG_64BIT) > +struct __svpbmt_struct __svpbmt __ro_after_init; > +EXPORT_SYMBOL(__svpbmt); > +#endif > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports 2021-11-30 18:46 ` Heiko Stübner @ 2021-12-01 3:00 ` Wei Fu 0 siblings, 0 replies; 35+ messages in thread From: Wei Fu @ 2021-12-01 3:00 UTC (permalink / raw) To: Heiko Stübner Cc: Anup Patel, atishp04, Palmer Dabbelt, Guo Ren, Christoph Müllner, Philipp Tomsich, Christoph Hellwig, Liu Shaohua, Wei Wu (吴伟), Drew Fustini, linux-riscv, Linux Kernel Mailing List, taiten.peng, Aniket Ponkshe, Heinrich Schuchardt, Gordan Markus, Guo Ren, Arnd Bergmann, Chen-Yu Tsai, Maxime Ripard, Daniel Lustig, Greg Favor, Andrea Mondelli, Jonathan Behrens, Xinhaoqu, Bill Huffman, Nick Kossifidis, Allen Baum, Josh Scheid, Richard Trauben, Palmer Dabbelt, Atish Patra Hi Heiko, thanks , yup, my typo, fixed in my new version . On Wed, Dec 1, 2021 at 2:46 AM Heiko Stübner <heiko@sntech.de> wrote: > > Am Montag, 29. November 2021, 02:40:07 CET schrieb wefu@redhat.com: > > From: Wei Fu <wefu@redhat.com> > > > > This patch follows the standard pure RISC-V Svpbmt extension in > > privilege spec to solve the non-coherent SOC dma synchronization > > issues. > > > > Here is the svpbmt PTE format: > > | 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > > N MT RSW D A G U X W R V > > ^ > > > > Of the Reserved bits [63:54] in a leaf PTE, the high bit is already > > allocated (as the N bit), so bits [62:61] are used as the MT (aka > > MemType) field. This field specifies one of three memory types that > > are close equivalents (or equivalent in effect) to the three main x86 > > and ARMv8 memory types - as shown in the following table. > > > > RISC-V > > Encoding & > > MemType RISC-V Description > > ---------- ------------------------------------------------ > > 00 - PMA Normal Cacheable, No change to implied PMA memory type > > 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory > > 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory > > 11 - Rsvd Reserved for future standard use > > > > The standard protection_map[] needn't be modified because the "PMA" > > type keeps the highest bits zero. And the whole modification is > > limited in the arch/riscv/* and using a global variable > > (__svpbmt) as _PAGE_MASK/IO/NOCACHE for pgprot_noncached > > (&writecombine) in pgtable.h. We also add _PAGE_CHG_MASK to filter > > PFN than before. > > > > Enable it in devicetree - (Add "riscv,svpbmt" in the mmu of cpu node) > > - mmu: > > riscv,svpmbt > > > > Signed-off-by: Wei Fu <wefu@redhat.com> > > Co-developed-by: Liu Shaohua <liush@allwinnertech.com> > > Signed-off-by: Liu Shaohua <liush@allwinnertech.com> > > Co-developed-by: Guo Ren <guoren@kernel.org> > > Signed-off-by: Guo Ren <guoren@kernel.org> > > Cc: Palmer Dabbelt <palmerdabbelt@google.com> > > Cc: Christoph Hellwig <hch@lst.de> > > Cc: Anup Patel <anup.patel@wdc.com> > > Cc: Arnd Bergmann <arnd@arndb.de> > > Cc: Atish Patra <atish.patra@wdc.com> > > Cc: Drew Fustini <drew@beagleboard.org> > > Cc: Wei Fu <wefu@redhat.com> > > Cc: Wei Wu <lazyparser@gmail.com> > > Cc: Chen-Yu Tsai <wens@csie.org> > > Cc: Maxime Ripard <maxime@cerno.tech> > > Cc: Daniel Lustig <dlustig@nvidia.com> > > Cc: Greg Favor <gfavor@ventanamicro.com> > > Cc: Andrea Mondelli <andrea.mondelli@huawei.com> > > Cc: Jonathan Behrens <behrensj@mit.edu> > > Cc: Xinhaoqu (Freddie) <xinhaoqu@huawei.com> > > Cc: Bill Huffman <huffman@cadence.com> > > Cc: Nick Kossifidis <mick@ics.forth.gr> > > Cc: Allen Baum <allen.baum@esperantotech.com> > > Cc: Josh Scheid <jscheid@ventanamicro.com> > > Cc: Richard Trauben <rtrauben@gmail.com> > > --- > > arch/riscv/include/asm/fixmap.h | 2 +- > > arch/riscv/include/asm/pgtable-64.h | 21 ++++++++++++--- > > arch/riscv/include/asm/pgtable-bits.h | 39 +++++++++++++++++++++++++-- > > arch/riscv/include/asm/pgtable.h | 39 ++++++++++++++++++++------- > > arch/riscv/kernel/cpufeature.c | 35 ++++++++++++++++++++++++ > > arch/riscv/mm/init.c | 5 ++++ > > 6 files changed, 126 insertions(+), 15 deletions(-) > > > > diff --git a/arch/riscv/include/asm/fixmap.h b/arch/riscv/include/asm/fixmap.h > > index 54cbf07fb4e9..5acd99d08e74 100644 > > --- a/arch/riscv/include/asm/fixmap.h > > +++ b/arch/riscv/include/asm/fixmap.h > > @@ -43,7 +43,7 @@ enum fixed_addresses { > > __end_of_fixed_addresses > > }; > > > > -#define FIXMAP_PAGE_IO PAGE_KERNEL > > +#define FIXMAP_PAGE_IO PAGE_IOREMAP > > > > #define __early_set_fixmap __set_fixmap > > > > diff --git a/arch/riscv/include/asm/pgtable-64.h b/arch/riscv/include/asm/pgtable-64.h > > index 228261aa9628..16d251282b1d 100644 > > --- a/arch/riscv/include/asm/pgtable-64.h > > +++ b/arch/riscv/include/asm/pgtable-64.h > > @@ -59,14 +59,29 @@ static inline void pud_clear(pud_t *pudp) > > set_pud(pudp, __pud(0)); > > } > > > > +static inline unsigned long _chg_of_pmd(pmd_t pmd) > > +{ > > + return (pmd_val(pmd) & _PAGE_CHG_MASK); > > +} > > + > > +static inline unsigned long _chg_of_pud(pud_t pud) > > +{ > > + return (pud_val(pud) & _PAGE_CHG_MASK); > > +} > > + > > +static inline unsigned long _chg_of_pte(pte_t pte) > > +{ > > + return (pte_val(pte) & _PAGE_CHG_MASK); > > +} > > + > > static inline pmd_t *pud_pgtable(pud_t pud) > > { > > - return (pmd_t *)pfn_to_virt(pud_val(pud) >> _PAGE_PFN_SHIFT); > > + return (pmd_t *)pfn_to_virt(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT); > > } > > > > static inline struct page *pud_page(pud_t pud) > > { > > - return pfn_to_page(pud_val(pud) >> _PAGE_PFN_SHIFT); > > + return pfn_to_page(_chg_of_pud(pud) >> _PAGE_PFN_SHIFT); > > } > > > > static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot) > > @@ -76,7 +91,7 @@ static inline pmd_t pfn_pmd(unsigned long pfn, pgprot_t prot) > > > > static inline unsigned long _pmd_pfn(pmd_t pmd) > > { > > - return pmd_val(pmd) >> _PAGE_PFN_SHIFT; > > + return _chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT; > > } > > > > #define mk_pmd(page, prot) pfn_pmd(page_to_pfn(page), prot) > > diff --git a/arch/riscv/include/asm/pgtable-bits.h b/arch/riscv/include/asm/pgtable-bits.h > > index 2ee413912926..e5b0fce4ddc5 100644 > > --- a/arch/riscv/include/asm/pgtable-bits.h > > +++ b/arch/riscv/include/asm/pgtable-bits.h > > @@ -7,7 +7,7 @@ > > #define _ASM_RISCV_PGTABLE_BITS_H > > > > /* > > - * PTE format: > > + * rv32 PTE format: > > * | XLEN-1 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > > * PFN reserved for SW D A G U X W R V > > */ > > @@ -24,6 +24,40 @@ > > #define _PAGE_DIRTY (1 << 7) /* Set by hardware on any write */ > > #define _PAGE_SOFT (1 << 8) /* Reserved for software */ > > > > +#if !defined(__ASSEMBLY__) && defined(CONFIG_64BIT) > > +/* > > + * rv64 PTE format: > > + * | 63 | 62 61 | 60 54 | 53 10 | 9 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > > + * N MT RSV PFN reserved for SW D A G U X W R V > > + * [62:61] Memory Type definitions: > > + * 00 - PMA Normal Cacheable, No change to implied PMA memory type > > + * 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory > > + * 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory > > + * 11 - Rsvd Reserved for future standard use > > + */ > > +#define _SVPBMT_PMA 0UL > > +#define _SVPBMT_NC (1UL << 61) > > +#define _SVPBMT_IO (1UL << 62) > > +#define _SVPBMT_MASK (_SVPBMT_NC | _SVPBMT_IO) > > + > > +extern struct __svpbmt_struct { > > + unsigned long mask; > > + unsigned long pma; > > + unsigned long nocache; > > + unsigned long io; > > +} __svpbmt __cacheline_aligned; > > + > > +#define _PAGE_MASK __svpbmt.mask > > +#define _PAGE_PMA __svpbmt.pma > > +#define _PAGE_NOCACHE __svpbmt.nocache > > +#define _PAGE_IO __svpbmt.io > > +#else > > +#define _PAGE_MASK 0 > > +#define _PAGE_PMA 0 > > +#define _PAGE_NOCACHE 0 > > +#define _PAGE_IO 0 > > +#endif /* !__ASSEMBLY__ && CONFIG_64BIT */ > > + > > #define _PAGE_SPECIAL _PAGE_SOFT > > #define _PAGE_TABLE _PAGE_PRESENT > > > > @@ -38,7 +72,8 @@ > > /* Set of bits to preserve across pte_modify() */ > > #define _PAGE_CHG_MASK (~(unsigned long)(_PAGE_PRESENT | _PAGE_READ | \ > > _PAGE_WRITE | _PAGE_EXEC | \ > > - _PAGE_USER | _PAGE_GLOBAL)) > > + _PAGE_USER | _PAGE_GLOBAL | \ > > + _PAGE_MASK)) > > /* > > * when all of R/W/X are zero, the PTE is a pointer to the next level > > * of the page table; otherwise, it is a leaf PTE. > > diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h > > index bf204e7c1f74..0f7a6541015f 100644 > > --- a/arch/riscv/include/asm/pgtable.h > > +++ b/arch/riscv/include/asm/pgtable.h > > @@ -138,7 +138,8 @@ > > | _PAGE_PRESENT \ > > | _PAGE_ACCESSED \ > > | _PAGE_DIRTY \ > > - | _PAGE_GLOBAL) > > + | _PAGE_GLOBAL \ > > + | _PAGE_PMA) > > > > #define PAGE_KERNEL __pgprot(_PAGE_KERNEL) > > #define PAGE_KERNEL_READ __pgprot(_PAGE_KERNEL & ~_PAGE_WRITE) > > @@ -148,11 +149,9 @@ > > > > #define PAGE_TABLE __pgprot(_PAGE_TABLE) > > > > -/* > > - * The RISC-V ISA doesn't yet specify how to query or modify PMAs, so we can't > > - * change the properties of memory regions. > > - */ > > -#define _PAGE_IOREMAP _PAGE_KERNEL > > +#define _PAGE_IOREMAP ((_PAGE_KERNEL & ~_PAGE_MASK) | _PAGE_IO) > > + > > +#define PAGE_IOREMAP __pgprot(_PAGE_IOREMAP) > > > > extern pgd_t swapper_pg_dir[]; > > > > @@ -232,12 +231,12 @@ static inline unsigned long _pgd_pfn(pgd_t pgd) > > > > static inline struct page *pmd_page(pmd_t pmd) > > { > > - return pfn_to_page(pmd_val(pmd) >> _PAGE_PFN_SHIFT); > > + return pfn_to_page(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT); > > } > > > > static inline unsigned long pmd_page_vaddr(pmd_t pmd) > > { > > - return (unsigned long)pfn_to_virt(pmd_val(pmd) >> _PAGE_PFN_SHIFT); > > + return (unsigned long)pfn_to_virt(_chg_of_pmd(pmd) >> _PAGE_PFN_SHIFT); > > } > > > > static inline pte_t pmd_pte(pmd_t pmd) > > @@ -253,7 +252,7 @@ static inline pte_t pud_pte(pud_t pud) > > /* Yields the page frame number (PFN) of a page table entry */ > > static inline unsigned long pte_pfn(pte_t pte) > > { > > - return (pte_val(pte) >> _PAGE_PFN_SHIFT); > > + return (_chg_of_pte(pte) >> _PAGE_PFN_SHIFT); > > } > > > > #define pte_page(x) pfn_to_page(pte_pfn(x)) > > @@ -492,6 +491,28 @@ static inline int ptep_clear_flush_young(struct vm_area_struct *vma, > > return ptep_test_and_clear_young(vma, address, ptep); > > } > > > > +#define pgprot_noncached pgprot_noncached > > +static inline pgprot_t pgprot_noncached(pgprot_t _prot) > > +{ > > + unsigned long prot = pgprot_val(_prot); > > + > > + prot &= ~_PAGE_MASK; > > + prot |= _PAGE_IO; > > + > > + return __pgprot(prot); > > +} > > + > > +#define pgprot_writecombine pgprot_writecombine > > +static inline pgprot_t pgprot_writecombine(pgprot_t _prot) > > +{ > > + unsigned long prot = pgprot_val(_prot); > > + > > + prot &= ~_PAGE_MASK; > > + prot |= _PAGE_NOCACHE; > > + > > + return __pgprot(prot); > > +} > > + > > /* > > * THP functions > > */ > > diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c > > index d959d207a40d..fa7480cb8b87 100644 > > --- a/arch/riscv/kernel/cpufeature.c > > +++ b/arch/riscv/kernel/cpufeature.c > > @@ -8,6 +8,7 @@ > > > > #include <linux/bitmap.h> > > #include <linux/of.h> > > +#include <linux/pgtable.h> > > #include <asm/processor.h> > > #include <asm/hwcap.h> > > #include <asm/smp.h> > > @@ -59,6 +60,38 @@ bool __riscv_isa_extension_available(const unsigned long *isa_bitmap, int bit) > > } > > EXPORT_SYMBOL_GPL(__riscv_isa_extension_available); > > > > +static void __init mmu_supports_svpbmt(void) > > +{ > > +#if defined(CONFIG_MMU) && defined(CONFIG_64BIT) > > + struct device_node *node; > > + const char *str; > > + > > + for_each_of_cpu_node(node) { > > + if (of_property_read_string(node, "mmu-type", &str)) > > + continue; > > + > > + if (!strncmp(str + 6, "none", 4)) > > + continue; > > + > > + if (of_property_read_string(node, "mmu", &str)) > > + continue; > > + > > + if (strncmp(str + 6, "svpmbt", 6)) > > same here ... check for "svpbmt" [m seems to be at the wrong position] > > > > + continue; > > + } > > + > > + __svpbmt.pma = _SVPBMT_PMA; > > + __svpbmt.nocache = _SVPBMT_NC; > > + __svpbmt.io = _SVPBMT_IO; > > + __svpbmt.mask = _SVPBMT_MASK; > > +#endif > > +} > > + > > +static void __init mmu_supports(void) > > +{ > > + mmu_supports_svpbmt(); > > +} > > + > > void __init riscv_fill_hwcap(void) > > { > > struct device_node *node; > > @@ -67,6 +100,8 @@ void __init riscv_fill_hwcap(void) > > size_t i, j, isa_len; > > static unsigned long isa2hwcap[256] = {0}; > > > > + mmu_supports(); > > + > > isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I; > > isa2hwcap['m'] = isa2hwcap['M'] = COMPAT_HWCAP_ISA_M; > > isa2hwcap['a'] = isa2hwcap['A'] = COMPAT_HWCAP_ISA_A; > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c > > index 24b2b8044602..e4e658165ee1 100644 > > --- a/arch/riscv/mm/init.c > > +++ b/arch/riscv/mm/init.c > > @@ -854,3 +854,8 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, > > return vmemmap_populate_basepages(start, end, node, NULL); > > } > > #endif > > + > > +#if defined(CONFIG_64BIT) > > +struct __svpbmt_struct __svpbmt __ro_after_init; > > +EXPORT_SYMBOL(__svpbmt); > > +#endif > > > > > > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [PATCH V4 0/2] riscv: add RISC-V Svpbmt Standard Extension supports 2021-11-29 1:40 [PATCH V4 0/2] riscv: add RISC-V Svpbmt Standard Extension supports wefu 2021-11-29 1:40 ` [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt wefu 2021-11-29 1:40 ` [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports wefu @ 2021-11-29 13:33 ` Jisheng Zhang 2 siblings, 0 replies; 35+ messages in thread From: Jisheng Zhang @ 2021-11-29 13:33 UTC (permalink / raw) To: wefu Cc: anup.patel, atishp04, palmer, guoren, christoph.muellner, philipp.tomsich, hch, liush, lazyparser, drew, linux-riscv, linux-kernel, taiten.peng, aniket.ponkshe, heinrich.schuchardt, gordan.markus, guoren, arnd, wens, maxime, dlustig, gfavor, andrea.mondelli, behrensj, xinhaoqu, huffman, mick, allen.baum, jscheid, rtrauben On Mon, 29 Nov 2021 09:40:05 +0800 wefu@redhat.com wrote: > From: Fu Wei <wefu@redhat.com> > > This patch follows the RISC-V standard Svpbmt extension in > privilege spec to solve the non-coherent SOC DMA synchronization > issues. > > The svpbmt PTE format: > | 63 | 62-61 | 60-8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 > N MT RSW D A G U X W R V > ^ > > Of the Reserved bits [63:54] in a leaf PTE, the bits [62:61] are used as > the MT (aka MemType) field. This field specifies one of three memory types > as shown in the following table: > MemType RISC-V Description > ---------- ------------------------------------------------ > 00 - PMA Normal Cacheable, No change to implied PMA memory type > 01 - NC Non-cacheable, idempotent, weakly-ordered Main Memory > 10 - IO Non-cacheable, non-idempotent, strongly-ordered I/O memory > 11 - Rsvd Reserved for future standard use > > The standard protection_map[] needn't be modified because the "PMA" > type keeps the highest bits zero. > And the whole modification is limited in the arch/riscv/* and using > a global variable(__svpbmt) as _PAGE_MASK/IO/NOCACHE for pgprot_noncached > (&writecombine) in pgtable.h. We also add _PAGE_CHG_MASK to filter > PFN than before. > > Enable it in devicetree - (Add "riscv,svpbmt" in the mmu of cpu node) > - mmu: > riscv,svpmbt > I noticed that this series goes up to v4 but changes history is missing. Will you add it? > Wei Fu (2): > dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt > riscv: add RISC-V Svpbmt extension supports > > .../devicetree/bindings/riscv/cpus.yaml | 10 +++++ > arch/riscv/include/asm/fixmap.h | 2 +- > arch/riscv/include/asm/pgtable-64.h | 21 ++++++++-- > arch/riscv/include/asm/pgtable-bits.h | 39 ++++++++++++++++++- > arch/riscv/include/asm/pgtable.h | 39 ++++++++++++++----- > arch/riscv/kernel/cpufeature.c | 35 +++++++++++++++++ > arch/riscv/mm/init.c | 5 +++ > 7 files changed, 136 insertions(+), 15 deletions(-) > ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2021-12-03 9:12 UTC | newest] Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-11-29 1:40 [PATCH V4 0/2] riscv: add RISC-V Svpbmt Standard Extension supports wefu 2021-11-29 1:40 ` [PATCH V4 1/2] dt-bindings: riscv: add MMU Standard Extensions support for Svpbmt wefu 2021-11-29 8:54 ` Heinrich Schuchardt 2021-11-29 12:06 ` Heiko Stübner 2021-11-30 12:07 ` Heiko Stübner 2021-11-30 13:17 ` Jessica Clarke 2021-11-30 13:27 ` Heiko Stübner 2021-11-30 13:59 ` Jessica Clarke 2021-11-30 15:01 ` Philipp Tomsich 2021-11-30 16:12 ` Jessica Clarke 2021-12-01 1:21 ` Atish Patra 2021-12-01 3:06 ` Tsukasa OI 2021-12-01 8:15 ` Atish Patra 2021-12-01 8:30 ` Heiko Stübner [not found] ` <CAELrHRDb9oeu_FokyhUFQ+Yu27=4xqvPdz4=08MXQzh3Bj2Myw@mail.gmail.com> 2021-12-01 10:20 ` Heiko Stübner 2021-12-01 11:05 ` Philipp Tomsich 2021-12-01 13:39 ` Jessica Clarke 2021-12-02 1:31 ` Tsukasa OI 2021-12-02 1:55 ` Atish Patra 2021-12-01 13:28 ` Heiko Stübner 2021-12-02 1:59 ` Atish Patra 2021-11-30 18:45 ` Heiko Stübner 2021-12-01 2:58 ` Wei Fu 2021-11-29 1:40 ` [PATCH V4 2/2] riscv: add RISC-V Svpbmt extension supports wefu 2021-11-29 10:48 ` Alexandre Ghiti 2021-11-29 13:36 ` Jisheng Zhang 2021-12-01 5:05 ` Wei Fu 2021-12-01 6:18 ` Anup Patel 2021-12-01 13:29 ` Jisheng Zhang 2021-12-03 9:12 ` Wei Fu 2021-11-30 10:18 ` Guo Ren 2021-12-01 3:03 ` Wei Fu 2021-11-30 18:46 ` Heiko Stübner 2021-12-01 3:00 ` Wei Fu 2021-11-29 13:33 ` [PATCH V4 0/2] riscv: add RISC-V Svpbmt Standard Extension supports Jisheng Zhang
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).