BPF ISA conformance groups

[dthaler1968@googlemail.com]

From David Vernet's WG summary:
> After this update, the discussion moved to a topic for the BPF ISA
document that has yet to be resolved:
> ISA RFC compliance. Dave pointed out that we still need to specify which
instructions in the ISA are
> MUST, SHOULD, etc, to ensure interoperability.  Several different options
were presented, including
>  having individual-instruction granularity, following the clang CPU
versioning convention, and grouping
> instructions by logical functionality.
>
> We did not obtain consensus at the conference on which was the best way
forward. Some of the points raised include the following:
>
> - Following the clang CPU versioning labels is somewhat arbitrary. It
>   may not be appropriate to standardize around grouping that is a result
>   of largely organic historical artifacts.
> - If we decide to do logical grouping, there is a danger of
>   bikeshedding. Looking at anecdotes from industry, some vendors such as
>   Netronome elected to not support particular instructions for
>   performance reasons.

My sense of the feedback in general was to group instructions by logical
functionality, and only create separate
conformance groups where there is some legitimate technical reason that a
runtime might not want to support
a given set of instructions.  Based on discussion during the meeting, here's
a strawman set of conformance
groups to kick off discussion.  I've tried to use short (like 6 characters
or fewer) names for ease of display in
document tables, and potentially in command line options to tools that might
want to use them.

A given runtime platform would be compliant to some set of the following
conformance groups:

1. "basic": all instructions not covered by another group below.
2. "atomic": all Atomic operations.  I think Christoph argued for this one
in the meeting.
3. "divide": all division and modulo operations.  Alexei said in the meeting
that he'd heard demand for this one.
4. "legacy": all legacy packet access instructions (deprecated).
5. "map": 64-bit immediate instructions that deal with map fds or map
indices.
6. "code": 64-bit immediate instruction that has a "code pointer" type.
7. "func": program-local functions.

Things that I *think* don't need a separate conformance group (can just be
in "basic") include:
a. Call helper function by address or BTF ID.  A runtime that doesn't
support these simply won't expose any
    such helper functions to BPF programs.
b. Platform variable instructions (dst = var_addr(imm)).  A runtime that
doesn't support this simply won't
    expose any platform variables to BPF programs.

Comments? (Let the bikeshedding begin...)

Dave