Re: [Bpf] BPF ISA conformance groups

[Alexei Starovoitov <[e-mail]>]

On Tue, Jan 23, 2024 at 3:29 PM <[e-mail]> wrote:
>
> > -----Original Message-----
> > From: David Vernet <[e-mail]>
> > Sent: Tuesday, January 23, 2024 1:40 PM
> > To: Jose E. Marchesi <[e-mail]>
> > Cc: Alexei Starovoitov <[e-mail]>; Christoph Hellwig
> > <[e-mail]>; Dave Thaler <[e-mail]>;
> > [e-mail]; bpf <[e-mail]>; Jakub Kicinski <[e-mail]>;
> > [e-mail]
> > Subject: Re: [Bpf] BPF ISA conformance groups
> >
> > On Tue, Jan 09, 2024 at 12:35:39PM +0100, Jose E. Marchesi wrote:
> > >
> > > > On Mon, Jan 8, 2024 at 8:00 AM Christoph Hellwig <[e-mail]>
> > wrote:
> > > >>
> > > >> On Fri, Jan 05, 2024 at 04:07:11PM -0600, David Vernet wrote:
> > > >> >
> > > >> > So how do we want to move forward here? It sounds like we're
> > > >> > leaning toward's Alexei's proposal of having:
> > > >> >
> > > >> > - Base Integer Instruction Set, 32-bit
> > > >> > - Base Integer Instruction Set, 64-bit
> > > >> > - Integer Multiplication and Division
> > > >> > - Atomic Instructions
> > > >>
> > > >> As in the 64-bit integer set would be an add-on to the first one
> > > >> which is the core set?  In that case that's fine with me, but the
> > > >> above wording is a bit suboptimal.
> > > >
> > > > yes.
> > > > Here is how I was thinking about the grouping:
> > > > 32-bit set: all 32-bit instructions those with BPF_ALU and BPF_JMP32
> > > > and load/store.
> > > >
> > > > 64-bit set: above plus BPF_ALU64 and BPF_JMP.
> > > >
> > > > The idea is to allow for clean 32-bit HW offloads.
> > > > We can introduce a compiler flag that will only use such
> > > > instructions and will error when 64-bit math is needed.
> > > > Details need to be thought through, of course.
> > > > Right now I'm not sure whether we need to reduce sizeof(void*) to 4
> > > > in such a case or normal 8 will still work, but from ISA perspective
> > > > everything is ready. 32-bit subregisters fit well.
> > > > The compiler work plus additional verifier smartness is needed, but
> > > > the end result should be very nice.
> > > > Offload of bpf programs into 32-bit embedded devices will be possible.
> > >
> > > This is very interesting.
> > this is necessarily something we need to figure out now. Hopefully this is all
> > stuff we can iron out once we start to really sink our teeth into the ABI doc.
>
> "Integer Multiplication and Division" in this thread doesn't seem to separate
> between 32-bit vs 64-bit.  Is the proposal that multiplication/division is ok
> to require 64-bit operations?  I had expected one rationale for the 32bit
> multiplication/division instructions is to accommodate 32-bit-only
> implementations.   So should we have separate groups for 32-bit vs
> 64-bit for the multiplication/division instructions?
>
> Similar question goes for the atomic instructions, i.e., should we
> have separate conformance groups for 32-bit vs 64-bit atomics?

risc-v defines only one group "M" for div/mul and another group "A"
for atomics.

What it means that groups "base32 + M" means that only 32-bit mul
is available while "base64 + M" means that both 32 and 64-bit alu is there.