Re: [PATCH 1/5] riscv: Checksum header

From: Conor Dooley
Date: Sun Aug 27 2023 - 08:26:26 EST


On Sun, Aug 27, 2023 at 11:28:33AM +0100, Conor Dooley wrote:
> On Sat, Aug 26, 2023 at 07:00:47PM -0700, Palmer Dabbelt wrote:
> > On Sat, 26 Aug 2023 18:42:41 PDT (-0700), Conor Dooley wrote:
> > > On Sat, Aug 26, 2023 at 06:26:06PM -0700, Charlie Jenkins wrote:
> > > > Provide checksum algorithms that have been designed to leverage riscv
> > > > instructions such as rotate. In 64-bit, can take advantage of the larger
> > > > register to avoid some overflow checking.
> > > >
> > > > Add configuration for Zba extension and add march for Zba and Zbb.
> > > >
> > > > Signed-off-by: Charlie Jenkins <charlie@xxxxxxxxxxxx>
> > > > ---
> > > > arch/riscv/Kconfig | 23 +++++++++++
> > > > arch/riscv/Makefile | 2 +
> > > > arch/riscv/include/asm/checksum.h | 86 +++++++++++++++++++++++++++++++++++++++
> > > > 3 files changed, 111 insertions(+)
> > > >
> > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > > > index 4c07b9189c86..8d7e475ca28d 100644
> > > > --- a/arch/riscv/Kconfig
> > > > +++ b/arch/riscv/Kconfig
> > > > @@ -507,6 +507,29 @@ config RISCV_ISA_V_DEFAULT_ENABLE
> > > > If you don't know what to do here, say Y.
> > > > +config TOOLCHAIN_HAS_ZBA
> > > > + bool
> > > > + default y
> > > > + depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64ima_zba)
> > > > + depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zba)
> > > > + depends on LLD_VERSION >= 150000 || LD_VERSION >= 23900
> > > > + depends on AS_HAS_OPTION_ARCH
> > > > +
> > > > +config RISCV_ISA_ZBA
> > > > + bool "Zba extension support for bit manipulation instructions"
> > > > + depends on TOOLCHAIN_HAS_ZBA
> > > > + depends on MMU
> > > > + depends on RISCV_ALTERNATIVE
> > > > + default y
> > > > + help
> > > > + Adds support to dynamically detect the presence of the ZBA
> > > > + extension (basic bit manipulation) and enable its usage.
> > > > +
> > > > + The Zba extension provides instructions to accelerate a number
> > > > + of bit-specific address creation operations.
> > > > +
> > > > + If you don't know what to do here, say Y.
> > > > +
> > > > config TOOLCHAIN_HAS_ZBB
> > > > bool
> > > > default y
> > > > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
> > > > index 6ec6d52a4180..51fa3f67fc9a 100644
> > > > --- a/arch/riscv/Makefile
> > > > +++ b/arch/riscv/Makefile
> > > > @@ -61,6 +61,8 @@ riscv-march-$(CONFIG_ARCH_RV64I) := rv64ima
> > > > riscv-march-$(CONFIG_FPU) := $(riscv-march-y)fd
> > > > riscv-march-$(CONFIG_RISCV_ISA_C) := $(riscv-march-y)c
> > > > riscv-march-$(CONFIG_RISCV_ISA_V) := $(riscv-march-y)v
> > > > +riscv-march-$(CONFIG_RISCV_ISA_ZBA) := $(riscv-march-y)_zba
> > > > +riscv-march-$(CONFIG_RISCV_ISA_ZBB) := $(riscv-march-y)_zbb
> > >
> > > AFAICT, this is going to break immediately on any system that enables
> > > RISCV_ISA_ZBA (which will happen by default) but does not support the
> > > extension. You made the option depend on RISCV_ALTERNATIVE, but I do
> > > not see any use of alternatives in the code to actually perform the
> > > dynamic detection of Zba.
> >
> > I guess we kind of have an ambiguity here: for stuff like C we just
> > unconditionally use the instructions, but for the rest we probe first. We
> > should probably have three states for each extension: disabled, dynamically
> > detected, and assumed.
>
> You mean, just add some comments to the makefile surrounding each
> section or to some rst documentation?

Also, the code here doesn't build w/
warning: invalid argument to '-march': '_zba_zbb_zicsr_zifencei_zihintpause'
so there's something else wrong with TOOLCHAIN_HAS_ZBA :)

>
> > > Note that for fd & v, we add it to riscv-march-y, but then immediately
> > > remove it again before passing to the compiler, only allow them in
> > > AFLAGS:
> > > # Remove F,D,V from isa string for all. Keep extensions between "fd" and "v" by
> > > # matching non-v and non-multi-letter extensions out with the filter ([^v_]*)
> > > KBUILD_CFLAGS += -march=$(shell echo $(riscv-march-y) | sed -E 's/(rv32ima|rv64ima)fd([^v_]*)v?/\1\2/')
> > >
> > > What am I missing?
> >
> > FD and V both have state that can be saved lazily, so we can't let arbitrary
> > code use them. The extensions formally known as B don't add state, so they
> > are safe to flip on in arbitrary places (aside from the issues you pointed
> > out above).
>
> I probably went about this badly since you missed the point. I was
> trying to point out that for anything other than the compressed
> extensions in the block above that we only pass them in march to the
> assembler, and not to the compiler, in contrast to this patch which just
> always passes them. I should have pointed to how we handled the
> in-kernel Zbb stuff & asked how this was any different, would probably
> have been clearer.
>



> _______________________________________________
> linux-riscv mailing list
> linux-riscv@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/linux-riscv

Attachment: signature.asc
Description: PGP signature