[PATCH bpf-next 2/5] riscv, bpf: Relax restrictions on Zbb instructions

[Conor Dooley]

On Tue, Apr 02, 2024 at 09:00:45PM +0200, Björn Töpel wrote:

> >> I still think Lehui's patch is correct; Building a kernel that can boot
> >> on multiple platforms (w/ or w/o Zbb support) and not having Zbb insn in
> >> the kernel proper, and iff Zbb is available at run-time the BPF JIT will
> >> emit Zbb.
> >
> > This sentence is -ENOPARSE to me, did you accidentally omit some words?
> > Additionally he config option has nothing to do with building kernels that
> > boot on multiple platforms, it only controls whether optimisations for Zbb
> > are built so that if Zbb is detected they can be used.
> 
> Ugh, sorry about that! I'm probably confused myself.

Reading this back, I a bunch of words too, so no worries...

> >> For these kind of optimizations, (IMO) it's better to let the BPF JIT
> >> decide at run-time.
> >
> > Why is bpf a different case to any other user in this regard?
> > I think that the commit message is misleading and needs to be changed,
> > because the point "the hardware is capable of recognising the Zbb
> > instructions independently..." is completely unrelated to the purpose
> > of the config option. Of course the hardware understanding the option

This should have been "understanding the instructions"...

> > has nothing to do with kernel configuration. The commit message needs to
> > explain why bpf is a special case and is exempt from an

And this s/from an//...

> > I totally understand any point about bpf being different in terms of
> > needing toolchain support, but IIRC it was I who pointed out up-thread.

And "pointed that out".

I always make a mess of these emails that I re-write several times :)

> > The part of the conversation that you're replying to here is about the
> > semantics of the Kconfig option and the original patch never mentioned
> > trying to avoid a dependency on toolchains at all, just kernel
> > configurations. The toolchain requirements I don't think are even super
> > hard to fulfill either - the last 3 versions of ld and lld all meet the
> > criteria.
> 
> Thanks for making it more clear, and I agree that the toolchain
> requirements are not hard to fulfull.
> 
> My view has been that "BPF is like userland", but I realize now that's
> odd.

Yeah, I can understand that perspective, but it does seem rather odd to
someone that isn't a bpf-ist.

> Let's make BPF similar to the rest of the RV kernel. If ZBB=n, then
> the BPF JIT doesn't know about emitting Zbb.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20240403/54b0b1ea/attachment.sig>