On Wed, Jun 9, 2021 at 5:45 PM Nick Kossifidis [off-list ref] wrote:

Στις 2021-06-09 06:28, Guo Ren έγραψε:

quoted

On Mon, Jun 7, 2021 at 2:14 AM Nick Kossifidis [off-list ref]
wrote:

quoted

Στις 2021-05-20 04:45, Guo Ren έγραψε:

quoted

On Wed, May 19, 2021 at 2:53 PM Christoph Hellwig [off-list ref] wrote:

quoted

On Tue, May 18, 2021 at 11:44:35PM -0700, Drew Fustini wrote:

quoted

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/