[RFC,0/3] Support using physical addresses for RISC-V CMO

Message

Icenowy Zheng Jan. 4, 2023, 7:41 a.m. UTC

Despite the official Zicbom extension only supports virtual addresses,
some vendor-specific extensions, e.g. Xtheadcmo, supports using directly
the physical address.

This patchset tries to provide a CMO alternative macro variant that is
feed with both VA and PA (and the used one can be picked at runtime),
implement it with PA on T-Head cores, and utilize this variant for some
situations that PA is easily accessible.

Tested with an LiteX SoC with OpenC906, with LiteSDCard as root device.

This patchset is based on the fix of dcache.cva encoding, which is at [1].
Without that patch applied, this patchset won't apply cleanly.

[1] https://patchwork.kernel.org/project/linux-riscv/patch/[e-mail]/

Icenowy Zheng (3):
  riscv: errata: cmo: add CMO macro variant with both VA and PA
  riscv: use VA+PA variant of CMO macros for DMA synchorization
  riscv: use VA+PA variant of CMO macros for DMA page preparation

 arch/riscv/include/asm/errata_list.h | 30 ++++++++++++++++++++++++++++
 arch/riscv/mm/dma-noncoherent.c      | 11 +++++-----
 2 files changed, 36 insertions(+), 5 deletions(-)

Comments

Icenowy Zheng Jan. 6, 2023, 7:38 a.m. UTC | #1

在 2023-01-04星期三的 13:16 +0100，Heiko Stübner写道：
> Hi,
> 
> Am Mittwoch, 4. Januar 2023, 10:27:53 CET schrieb Icenowy Zheng:
> > 在 2023-01-04星期三的 17:24 +0800，Guo Ren写道：
> > > On Wed, Jan 4, 2023 at 4:59 PM Icenowy Zheng <[e-mail]>
> > > wrote:
> > > > 
> > > > 在 2023-01-04星期三的 16:50 +0800，Guo Ren写道：
> > > > > On Wed, Jan 4, 2023 at 3:43 PM Icenowy Zheng <[e-mail]>
> > > > > wrote:
> > > > > > 
> > > > > > DMA synchorization is done on PA and the VA is calculated
> > > > > > from
> > > > > > the
> > > > > > PA.
> > > > > > 
> > > > > > Use the alternative macro variant that takes both VA and PA
> > > > > > as
> > > > > > parameters, thus in case the ISA extension used support PA
> > > > > > directly, the
> > > > > > overhead for re-converting VA to PA can be omitted.
> > > > > > 
> > > > > > Suggested-by: Guo Ren <[e-mail]>
> > > > > > Signed-off-by: Icenowy Zheng <[e-mail]>
> > > > > > ---
> > > > > >  arch/riscv/mm/dma-noncoherent.c | 8 ++++----
> > > > > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > > > > > 
> > > > > > diff --git a/arch/riscv/mm/dma-noncoherent.c
> > > > > > b/arch/riscv/mm/dma-
> > > > > > noncoherent.c
> > > > > > index d919efab6eba..a751f4aece62 100644
> > > > > > --- a/arch/riscv/mm/dma-noncoherent.c
> > > > > > +++ b/arch/riscv/mm/dma-noncoherent.c
> > > > > > @@ -19,13 +19,13 @@ void
> > > > > > arch_sync_dma_for_device(phys_addr_t
> > > > > > paddr, size_t size,
> > > > > > 
> > > > > >         switch (dir) {
> > > > > >         case DMA_TO_DEVICE:
> > > > > > -               ALT_CMO_OP(clean, vaddr, size,
> > > > > > riscv_cbom_block_size);
> > > > > > +               ALT_CMO_OP_VPA(clean, vaddr, paddr, size,
> > > > > > riscv_cbom_block_size);
> > > > > ALT_CMO_OP -> ALT_CMO_OP_VPA, is the renaming necessary?
> > > > 
> > > > I didn't rename the original ALT_CMO_OP, ALT_CMO_OP_VPA is
> > > > something
> > > > new.
> > > The ##_VPA is really strange.
> > > 
> > > How about:
> > > ALT_CMO_OP          -> ALT_CMO_OP_VA
> > > ALT_CMO_OP_VPA -> ALT_CMO_OP
> > 
> > It's thus a much bigger change.
> > 
> > If you are not fond of _VPA, I can rename it to _VA_PA.
> 
> before you spend too much time on this, there is currently a parallel
> discussion running about including all the other different vendor-
> specific cache management.
> 
> See [0] and the thread before that for reference.

The code shown here seems to be only a draft, and not even testable.

> 
> The consensus seems to be that cache-handling itself is not fast
> anyway,
> and therefore to reduce complexity for the cache handling and move
> non-zicbom cache-handling into a indirect function call that the can
> be
> overridden at runtime.

Well yes I tested this patchset on my LiteX with OpenC906, and it does
not help at all on LiteETH throughtput. So maybe this is only some
theortical gain.

> 
> 
> Heiko
> 
> [0]
> https://lore.kernel.org/all/[e-mail]/
> 
>