From: Guo Ren <guoren@kernel.org> To: Nick Kossifidis <mick@ics.forth.gr> Cc: "Christoph Hellwig" <hch@lst.de>, "Drew Fustini" <drew@beagleboard.org>, "Anup Patel" <anup.patel@wdc.com>, "Palmer Dabbelt" <palmerdabbelt@google.com>, wefu@redhat.com, "Wei Wu (吴伟)" <lazyparser@gmail.com>, linux-riscv <linux-riscv@lists.infradead.org>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, linux-arch <linux-arch@vger.kernel.org>, linux-sunxi@lists.linux.dev, "Guo Ren" <guoren@linux.alibaba.com>, "Paul Walmsley" <paul.walmsley@sifive.com>, "Benjamin Koch" <snowball@c3pb.de>, "Matteo Croce" <mcroce@linux.microsoft.com>, "Wei Fu" <tekkamanninja@gmail.com> Subject: Re: [PATCH RFC 0/3] riscv: Add DMA_COHERENT support Date: Wed, 9 Jun 2021 20:43:43 +0800 [thread overview] Message-ID: <CAJF2gTSko9yu_Hqgu3vOzjS=uPKC8jaLdgkAXx1BW2k26uuJRg@mail.gmail.com> (raw) In-Reply-To: <78f544f739120f5b541238a1d5f6e23b@mailhost.ics.forth.gr> On Wed, Jun 9, 2021 at 5:45 PM Nick Kossifidis <mick@ics.forth.gr> wrote: > > Στις 2021-06-09 06:28, Guo Ren έγραψε: > > On Mon, Jun 7, 2021 at 2:14 AM Nick Kossifidis <mick@ics.forth.gr> > > wrote: > >> > >> Στις 2021-05-20 04:45, Guo Ren έγραψε: > >> > On Wed, May 19, 2021 at 2:53 PM Christoph Hellwig <hch@lst.de> wrote: > >> >> > >> >> On Tue, May 18, 2021 at 11:44:35PM -0700, Drew Fustini wrote: > >> >> > This patch series looks like it might be useful for the StarFive JH7100 > >> >> > [1] [2] too as it has peripherals on a non-coherent interconnect. GMAC, > >> >> > USB and SDIO require that the L2 cache must be manually flushed after > >> >> > DMA operations if the data is intended to be shared with U74 cores [2]. > >> >> > >> >> Not too much, given that the SiFive lineage CPUs have an uncached > >> >> window, that is a totally different way to allocate uncached memory. > >> > It's a very big MIPS smell. What's the attribute of the uncached > >> > window? (uncached + strong-order/ uncached + weak, most vendors still > >> > use AXI interconnect, how to deal with a bufferable attribute?) In > >> > fact, customers' drivers use different ways to deal with DMA memory in > >> > non-coherent SOC. Most riscv SOC vendors are from ARM, so giving them > >> > the same way in DMA memory is a smart choice. So using PTE attributes > >> > is more suitable. > >> > > >> > See: > >> > https://github.com/riscv/virtual-memory/blob/main/specs/611-virtual-memory-diff.pdf > >> > 4.4.1 > >> > The draft supports custom attribute bits in PTE. > >> > > >> > >> Not only it doesn't support custom attributes on PTEs: > >> > >> "Bits63–54 are reserved for future standard use and must be zeroed by > >> software for forward compatibility." > >> > >> It also goes further to say that: > >> > >> "if any of these bits are set, a page-fault exception is raised" > > Agree, when our processor's mmu works in compatible mmu, we must keep > > "Bits63–54 bit" zero in Linux. > > So, I think this is the first version of the PTE format. > > > > If the "PBMT" extension proposal is approved, it will cause the second > > version of the PTE format. > > > > Maybe in the future, we'll get more versions of the PTE formats. > > > > So, seems Linux must support multi versions of PTE formats with one > > Image, right? > > > > Okay, we could stop arguing with the D1 PTE format. And talk about how > > to let Linux support multi versions of PTE formats that come from the > > future RISC-V privilege spec. > > The RISC-V ISA specs are meant to be backwards compatible, so newer PTE > versions should work on older devices (note that the spec says that > software must set those bits to zero for "forward compatibility" and are > "reserved for future use" so current implementations must ignore them). > Obviously the proposed "if any of these bits are set, a page-fault > exception is raised" will break backwards compatibility which is why we > need to ask for it to be removed from the draft. > > As an example the PBMT proposal uses bits 62:61 that on older hw should > be ignored ("reserved for future use"), if Linux uses those bits we > won't need a different code path for supporting older hw/older PTE > versions, we'll just set them and older hw will ignore them. Because of > the guarantee that ISA specs maintain backwards compatibility, the > functionality of bits 62:61 is guaranteed to remain backwards > compatible. the spec says that software must set those bits to zero for "forward compatibility". So how older hw ignore them? If an older hw follow the current spec requires software to set those bits to zero, how we put any PBMT bits without different Linux PTE formats? > > In other words we don't need any special handling of multiple PTE > formats, we just need to support the latest Priv. Spec and the Spec > itself will guarantee backwards compatibility. Nak, totally no Logically self-consistent. -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/
WARNING: multiple messages have this Message-ID (diff)
From: Guo Ren <guoren@kernel.org> To: Nick Kossifidis <mick@ics.forth.gr> Cc: "Christoph Hellwig" <hch@lst.de>, "Drew Fustini" <drew@beagleboard.org>, "Anup Patel" <anup.patel@wdc.com>, "Palmer Dabbelt" <palmerdabbelt@google.com>, wefu@redhat.com, "Wei Wu (吴伟)" <lazyparser@gmail.com>, linux-riscv <linux-riscv@lists.infradead.org>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, linux-arch <linux-arch@vger.kernel.org>, linux-sunxi@lists.linux.dev, "Guo Ren" <guoren@linux.alibaba.com>, "Paul Walmsley" <paul.walmsley@sifive.com>, "Benjamin Koch" <snowball@c3pb.de>, "Matteo Croce" <mcroce@linux.microsoft.com>, "Wei Fu" <tekkamanninja@gmail.com> Subject: Re: [PATCH RFC 0/3] riscv: Add DMA_COHERENT support Date: Wed, 9 Jun 2021 20:43:43 +0800 [thread overview] Message-ID: <CAJF2gTSko9yu_Hqgu3vOzjS=uPKC8jaLdgkAXx1BW2k26uuJRg@mail.gmail.com> (raw) In-Reply-To: <78f544f739120f5b541238a1d5f6e23b@mailhost.ics.forth.gr> On Wed, Jun 9, 2021 at 5:45 PM Nick Kossifidis <mick@ics.forth.gr> wrote: > > Στις 2021-06-09 06:28, Guo Ren έγραψε: > > On Mon, Jun 7, 2021 at 2:14 AM Nick Kossifidis <mick@ics.forth.gr> > > wrote: > >> > >> Στις 2021-05-20 04:45, Guo Ren έγραψε: > >> > On Wed, May 19, 2021 at 2:53 PM Christoph Hellwig <hch@lst.de> wrote: > >> >> > >> >> On Tue, May 18, 2021 at 11:44:35PM -0700, Drew Fustini wrote: > >> >> > This patch series looks like it might be useful for the StarFive JH7100 > >> >> > [1] [2] too as it has peripherals on a non-coherent interconnect. GMAC, > >> >> > USB and SDIO require that the L2 cache must be manually flushed after > >> >> > DMA operations if the data is intended to be shared with U74 cores [2]. > >> >> > >> >> Not too much, given that the SiFive lineage CPUs have an uncached > >> >> window, that is a totally different way to allocate uncached memory. > >> > It's a very big MIPS smell. What's the attribute of the uncached > >> > window? (uncached + strong-order/ uncached + weak, most vendors still > >> > use AXI interconnect, how to deal with a bufferable attribute?) In > >> > fact, customers' drivers use different ways to deal with DMA memory in > >> > non-coherent SOC. Most riscv SOC vendors are from ARM, so giving them > >> > the same way in DMA memory is a smart choice. So using PTE attributes > >> > is more suitable. > >> > > >> > See: > >> > https://github.com/riscv/virtual-memory/blob/main/specs/611-virtual-memory-diff.pdf > >> > 4.4.1 > >> > The draft supports custom attribute bits in PTE. > >> > > >> > >> Not only it doesn't support custom attributes on PTEs: > >> > >> "Bits63–54 are reserved for future standard use and must be zeroed by > >> software for forward compatibility." > >> > >> It also goes further to say that: > >> > >> "if any of these bits are set, a page-fault exception is raised" > > Agree, when our processor's mmu works in compatible mmu, we must keep > > "Bits63–54 bit" zero in Linux. > > So, I think this is the first version of the PTE format. > > > > If the "PBMT" extension proposal is approved, it will cause the second > > version of the PTE format. > > > > Maybe in the future, we'll get more versions of the PTE formats. > > > > So, seems Linux must support multi versions of PTE formats with one > > Image, right? > > > > Okay, we could stop arguing with the D1 PTE format. And talk about how > > to let Linux support multi versions of PTE formats that come from the > > future RISC-V privilege spec. > > The RISC-V ISA specs are meant to be backwards compatible, so newer PTE > versions should work on older devices (note that the spec says that > software must set those bits to zero for "forward compatibility" and are > "reserved for future use" so current implementations must ignore them). > Obviously the proposed "if any of these bits are set, a page-fault > exception is raised" will break backwards compatibility which is why we > need to ask for it to be removed from the draft. > > As an example the PBMT proposal uses bits 62:61 that on older hw should > be ignored ("reserved for future use"), if Linux uses those bits we > won't need a different code path for supporting older hw/older PTE > versions, we'll just set them and older hw will ignore them. Because of > the guarantee that ISA specs maintain backwards compatibility, the > functionality of bits 62:61 is guaranteed to remain backwards > compatible. the spec says that software must set those bits to zero for "forward compatibility". So how older hw ignore them? If an older hw follow the current spec requires software to set those bits to zero, how we put any PBMT bits without different Linux PTE formats? > > In other words we don't need any special handling of multiple PTE > formats, we just need to support the latest Priv. Spec and the Spec > itself will guarantee backwards compatibility. Nak, totally no Logically self-consistent. -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/ _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2021-06-09 12:44 UTC|newest] Thread overview: 112+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-05-19 5:04 [PATCH RFC 0/3] riscv: Add DMA_COHERENT support guoren 2021-05-19 5:04 ` guoren 2021-05-19 5:04 ` [PATCH RFC 1/3] riscv: pgtable.h: Fixup _PAGE_CHG_MASK usage guoren 2021-05-19 5:04 ` guoren 2021-05-19 5:04 ` [PATCH RFC 2/3] riscv: Add DMA_COHERENT for custom PTE attributes guoren 2021-05-19 5:04 ` guoren 2021-05-19 5:04 ` [PATCH RFC 3/3] riscv: Add SYNC_DMA_FOR_CPU/DEVICE for DMA_COHERENT guoren 2021-05-19 5:04 ` guoren 2021-05-19 6:32 ` Guo Ren 2021-05-19 6:32 ` Guo Ren 2021-05-19 5:20 ` [PATCH RFC 0/3] riscv: Add DMA_COHERENT support Christoph Hellwig 2021-05-19 5:20 ` Christoph Hellwig 2021-05-19 5:48 ` Guo Ren 2021-05-19 5:48 ` Guo Ren 2021-05-19 5:55 ` Christoph Hellwig 2021-05-19 5:55 ` Christoph Hellwig 2021-05-19 6:09 ` Guo Ren 2021-05-19 6:09 ` Guo Ren 2021-05-19 6:44 ` Drew Fustini 2021-05-19 6:44 ` Drew Fustini 2021-05-19 6:53 ` Christoph Hellwig 2021-05-19 6:53 ` Christoph Hellwig 2021-05-20 1:45 ` Guo Ren 2021-05-20 1:45 ` Guo Ren 2021-05-20 5:48 ` Christoph Hellwig 2021-05-20 5:48 ` Christoph Hellwig 2021-06-06 18:14 ` Nick Kossifidis 2021-06-06 18:14 ` Nick Kossifidis 2021-06-07 0:04 ` Guo Ren 2021-06-07 0:04 ` Guo Ren 2021-06-07 2:16 ` Nick Kossifidis 2021-06-07 2:16 ` Nick Kossifidis 2021-06-07 3:19 ` Guo Ren 2021-06-07 3:19 ` Guo Ren 2021-06-07 6:27 ` Christoph Hellwig 2021-06-07 6:27 ` Christoph Hellwig 2021-06-07 6:41 ` Guo Ren 2021-06-07 6:41 ` Guo Ren 2021-06-07 6:51 ` Christoph Hellwig 2021-06-07 6:51 ` Christoph Hellwig 2021-06-07 7:46 ` Guo Ren 2021-06-07 7:46 ` Guo Ren 2021-06-08 15:00 ` David Laight 2021-06-08 15:00 ` David Laight 2021-06-08 15:32 ` 'Christoph Hellwig' 2021-06-08 15:32 ` 'Christoph Hellwig' 2021-06-08 16:11 ` David Laight 2021-06-08 16:11 ` David Laight 2021-06-07 8:35 ` Nick Kossifidis 2021-06-07 8:35 ` Nick Kossifidis 2021-06-09 3:28 ` Guo Ren 2021-06-09 3:28 ` Guo Ren 2021-06-09 6:05 ` Jisheng Zhang 2021-06-09 6:05 ` Jisheng Zhang 2021-06-09 9:45 ` Nick Kossifidis 2021-06-09 9:45 ` Nick Kossifidis 2021-06-09 12:43 ` Guo Ren [this message] 2021-06-09 12:43 ` Guo Ren 2021-05-19 6:05 ` Guo Ren 2021-05-19 6:05 ` Guo Ren 2021-05-19 6:06 ` Christoph Hellwig 2021-05-19 6:06 ` Christoph Hellwig 2021-05-19 6:11 ` Guo Ren 2021-05-19 6:11 ` Guo Ren 2021-05-19 6:54 ` Drew Fustini 2021-05-19 6:54 ` Drew Fustini 2021-05-19 6:56 ` Christoph Hellwig 2021-05-19 6:56 ` Christoph Hellwig 2021-05-19 7:14 ` Anup Patel 2021-05-19 7:14 ` Anup Patel 2021-05-19 8:25 ` Damien Le Moal 2021-05-19 8:25 ` Damien Le Moal 2021-05-20 1:47 ` Guo Ren 2021-05-20 1:47 ` Guo Ren 2021-05-20 1:59 ` Guo Ren 2021-05-20 1:59 ` Guo Ren 2021-05-22 0:36 ` Guo Ren 2021-05-22 0:36 ` Guo Ren 2021-05-30 0:30 ` Palmer Dabbelt 2021-05-30 0:30 ` Palmer Dabbelt 2021-06-03 4:13 ` Palmer Dabbelt 2021-06-03 4:13 ` Palmer Dabbelt 2021-06-03 6:00 ` Anup Patel 2021-06-03 6:00 ` Anup Patel 2021-06-03 15:39 ` Palmer Dabbelt 2021-06-03 15:39 ` Palmer Dabbelt 2021-06-04 9:02 ` David Laight 2021-06-04 9:02 ` David Laight 2021-06-04 9:53 ` Arnd Bergmann 2021-06-04 9:53 ` Arnd Bergmann 2021-06-04 14:47 ` Guo Ren 2021-06-04 14:47 ` Guo Ren 2021-06-04 16:12 ` Palmer Dabbelt 2021-06-04 16:12 ` Palmer Dabbelt 2021-06-04 21:26 ` Arnd Bergmann 2021-06-04 21:26 ` Arnd Bergmann 2021-06-04 22:10 ` Palmer Dabbelt 2021-06-04 22:10 ` Palmer Dabbelt 2021-06-08 12:26 ` Guo Ren 2021-06-08 12:26 ` Guo Ren 2021-06-06 17:11 ` Guo Ren 2021-06-06 17:11 ` Guo Ren 2021-06-07 3:38 ` Anup Patel 2021-06-07 3:38 ` Anup Patel 2021-06-07 4:22 ` Guo Ren 2021-06-07 4:22 ` Guo Ren 2021-06-07 4:47 ` Anup Patel 2021-06-07 4:47 ` Anup Patel 2021-06-07 5:08 ` Guo Ren 2021-06-07 5:08 ` Guo Ren 2021-06-07 5:13 ` Guo Ren 2021-06-07 5:13 ` Guo Ren
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAJF2gTSko9yu_Hqgu3vOzjS=uPKC8jaLdgkAXx1BW2k26uuJRg@mail.gmail.com' \ --to=guoren@kernel.org \ --cc=anup.patel@wdc.com \ --cc=drew@beagleboard.org \ --cc=guoren@linux.alibaba.com \ --cc=hch@lst.de \ --cc=lazyparser@gmail.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-riscv@lists.infradead.org \ --cc=linux-sunxi@lists.linux.dev \ --cc=mcroce@linux.microsoft.com \ --cc=mick@ics.forth.gr \ --cc=palmerdabbelt@google.com \ --cc=paul.walmsley@sifive.com \ --cc=snowball@c3pb.de \ --cc=tekkamanninja@gmail.com \ --cc=wefu@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.