Re: [Bpf] BPF ISA conformance groups

[David Vernet <void@manifault.com>]

[-- Attachment #1: Type: text/plain, Size: 1682 bytes --]

On Wed, Dec 20, 2023 at 11:00:59PM -0800, Christoph Hellwig wrote:
> On Tue, Dec 19, 2023 at 07:28:10PM -0800, Alexei Starovoitov wrote:
> > Right, but bringing the verifier into the "compliance picture"
> > makes the ISA standard incomplete.
> > Same can be said about nfp compliance. It's compliant with an ISA,
> > but the verifier will reject things it doesn't support.
> 
> Yes, that's a good point.  Especially for anything call related I think
> it's fine to say they are a mandatory part of the basic some coarse
> group, but a given program type might not support it, but that is
> enforced by the verifier as the compiler should not have to known about
> the program type.

Agreed as well.

> 
> > All ld_imm64 and call insns look the same. The compiler emits
> > them the same way.
> > The src_reg encoding is what libbpf does based on compiler relocations.
> > 
> > Then the verifier checks them differently and later JIT sees
> > _all_ ld_imm64 as one type of instruction.
> > Same with call insn. To x86/arm64/riscv JITs there is only one BPF CALL insn.
> 
> Yup.  Another case for ISA supported vs program type supported (and
> enforced by the verifier).

+1

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

And then either having 3 separate groups for the calls, or putting all 3
in the basic group? I'd lean towards the latter given that we're
decoupling ISA compliance from the verifier, but don't feel strongly
either way.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]