On Thu, Feb 8, 2024 at 5:32 PM Dave Thaler <dthaler1968=40googlemail.com@xxxxxxxxxxxxxx> wrote: > > * Add a "callx" conformance group > * Add callx rows to table > * Update helper function to section to be agnostic between BPF_K vs > BPF_X > * Rename "legacy" conformance group to "packet" > > Based on mailing list discussion at > https://mailarchive.ietf.org/arch/msg/bpf/l5tNEgL-Wo7qSEuaGssOl5VChKk/ > > Signed-off-by: Dave Thaler <dthaler1968@xxxxxxxxx> > --- > .../bpf/standardization/instruction-set.rst | 32 ++++++++++++------- > 1 file changed, 21 insertions(+), 11 deletions(-) > > diff --git a/Documentation/bpf/standardization/instruction-set.rst b/Documentation/bpf/standardization/instruction-set.rst > index bdfe0cd0e..8f0ada22e 100644 > --- a/Documentation/bpf/standardization/instruction-set.rst > +++ b/Documentation/bpf/standardization/instruction-set.rst > @@ -127,7 +127,7 @@ This document defines the following conformance groups: > * divmul32: includes 32-bit division, multiplication, and modulo instructions. > * divmul64: includes divmul32, plus 64-bit division, multiplication, > and modulo instructions. > -* legacy: deprecated packet access instructions. > +* packet: deprecated packet access instructions. > > Instruction encoding > ==================== > @@ -404,9 +404,12 @@ BPF_JSET 0x4 any PC += offset if dst & src > BPF_JNE 0x5 any PC += offset if dst != src > BPF_JSGT 0x6 any PC += offset if dst > src signed > BPF_JSGE 0x7 any PC += offset if dst >= src signed > -BPF_CALL 0x8 0x0 call helper function by address BPF_JMP | BPF_K only, see `Helper functions`_ > +BPF_CALL 0x8 0x0 call_by_address(imm) BPF_JMP | BPF_K only > +BPF_CALL 0x8 0x0 call_by_address(reg_val(imm)) BPF_JMP | BPF_X only > BPF_CALL 0x8 0x1 call PC += imm BPF_JMP | BPF_K only, see `Program-local functions`_ > -BPF_CALL 0x8 0x2 call helper function by BTF ID BPF_JMP | BPF_K only, see `Helper functions`_ > +BPF_CALL 0x8 0x1 call PC += reg_val(imm) BPF_JMP | BPF_X only, see `Program-local functions`_ > +BPF_CALL 0x8 0x2 call_by_btfid(imm) BPF_JMP | BPF_K only > +BPF_CALL 0x8 0x2 call_by_btfid(reg_val(imm)) BPF_JMP | BPF_X only > BPF_EXIT 0x9 0x0 return BPF_JMP | BPF_K only > BPF_JLT 0xa any PC += offset if dst < src unsigned > BPF_JLE 0xb any PC += offset if dst <= src unsigned > @@ -414,6 +417,12 @@ BPF_JSLT 0xc any PC += offset if dst < src signed > BPF_JSLE 0xd any PC += offset if dst <= src signed > ======== ===== === =============================== ============================================= > > +where > + > +* reg_val(imm) gets the value of the register with the specified number > +* call_by_address(value) means to call a helper function by address (see `Helper functions`_ for details) > +* call_by_btfid(value) means to call a helper function by BTF ID (see `Helper functions`_ for details) > + Could we say * reg_val(imm) gets the value of the register specified by ``imm`` * call_by_address(value) means to call a helper function by address specified by ``value`` (see `Helper functions`_ for details) * call_by_btfid(value) means to call a helper function by BTF ID specified by ``value`` (see `Helper functions`_ for details) I'm not sure that it helps, but I thought I would offer the suggestion. Otherwise, looks good to me! Will > The BPF program needs to store the return value into register R0 before doing a > ``BPF_EXIT``. > > @@ -438,8 +447,9 @@ specified by the 'imm' field. A > 16-bit conditional jump may be > converted to a < 16-bit conditional jump plus a 32-bit unconditional > jump. > > -All ``BPF_CALL`` and ``BPF_JA`` instructions belong to the > -base32 conformance group. > +All ``BPF_CALL | BPF_X`` instructions belong to the callx > +conformance group. All other ``BPF_CALL`` instructions and all > +``BPF_JA`` instructions belong to the base32 conformance group. > > Helper functions > ~~~~~~~~~~~~~~~~ > @@ -447,13 +457,13 @@ Helper functions > Helper functions are a concept whereby BPF programs can call into a > set of function calls exposed by the underlying platform. > > -Historically, each helper function was identified by an address > -encoded in the imm field. The available helper functions may differ > -for each program type, but address values are unique across all program types. > +Historically, each helper function was identified by an address. > +The available helper functions may differ for each program type, > +but address values are unique across all program types. > > Platforms that support the BPF Type Format (BTF) support identifying > -a helper function by a BTF ID encoded in the imm field, where the BTF ID > -identifies the helper name and type. > +a helper function by a BTF ID, where the BTF ID identifies the helper > +name and type. > > Program-local functions > ~~~~~~~~~~~~~~~~~~~~~~~ > @@ -660,4 +670,4 @@ carried over from classic BPF. These instructions used an instruction > class of BPF_LD, a size modifier of BPF_W, BPF_H, or BPF_B, and a > mode modifier of BPF_ABS or BPF_IND. However, these instructions are > deprecated and should no longer be used. All legacy packet access > -instructions belong to the "legacy" conformance group. > +instructions belong to the "packet" conformance group. > -- > 2.40.1 > > -- > Bpf mailing list > Bpf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/bpf
