On Sat, Mar 25, 2023 at 10:49 PM Dave Thaler <dthaler1968=40googlemail.com@xxxxxxxxxxxxxx> wrote: > > From: Dave Thaler <dthaler@xxxxxxxxxxxxx> > > Add docs on extended 64-bit immediate instructions, including six instructions > previously undocumented. Include a brief description of maps and variables, > as used by those instructions. > > V1 -> V2: rebased on top of latest master > > V2 -> V3: addressed comments from Alexei > > V3 -> V4: addressed comments from David Vernet > > Signed-off-by: Dave Thaler <dthaler@xxxxxxxxxxxxx> > --- > Documentation/bpf/instruction-set.rst | 57 +++++++++++++++++++++++---- > Documentation/bpf/linux-notes.rst | 22 +++++++++++ > 2 files changed, 71 insertions(+), 8 deletions(-) > > diff --git a/Documentation/bpf/instruction-set.rst b/Documentation/bpf/instruction-set.rst > index b4464058905..b3efa4b74ec 100644 > --- a/Documentation/bpf/instruction-set.rst > +++ b/Documentation/bpf/instruction-set.rst > @@ -401,14 +401,55 @@ and loaded back to ``R0``. > ----------------------------- > > Instructions with the ``BPF_IMM`` 'mode' modifier use the wide instruction > -encoding for an extra imm64 value. > - > -There is currently only one such instruction. > - > -``BPF_LD | BPF_DW | BPF_IMM`` means:: > - > - dst = imm64 > - > +encoding defined in `Instruction encoding`_, and use the 'src' field of the > +basic instruction to hold an opcode subtype. > + > +The following table defines a set of ``BPF_IMM | BPF_DW | BPF_LD`` instructions > +with opcode subtypes in the 'src' field, using new terms such as "map" > +defined further below: > + > +========================= ====== === ========================================= =========== ============== > +opcode construction opcode src pseudocode imm type dst type > +========================= ====== === ========================================= =========== ============== > +BPF_IMM | BPF_DW | BPF_LD 0x18 0x0 dst = imm64 integer integer > +BPF_IMM | BPF_DW | BPF_LD 0x18 0x1 dst = map_by_fd(imm) map fd map > +BPF_IMM | BPF_DW | BPF_LD 0x18 0x2 dst = map_val(map_by_fd(imm)) + next_imm map fd data pointer > +BPF_IMM | BPF_DW | BPF_LD 0x18 0x3 dst = var_addr(imm) variable id data pointer > +BPF_IMM | BPF_DW | BPF_LD 0x18 0x4 dst = code_addr(imm) integer code pointer > +BPF_IMM | BPF_DW | BPF_LD 0x18 0x5 dst = map_by_idx(imm) map index map > +BPF_IMM | BPF_DW | BPF_LD 0x18 0x6 dst = map_val(map_by_idx(imm)) + next_imm map index data pointer > +========================= ====== === ========================================= =========== ============== > + > +where > + > +* map_by_fd(imm) means to convert a 32-bit POSIX file descriptor into an address of a map (see `Maps`_) I removed the screaming "POSIX" word, since "file descriptor" is descriptive enough. > +* map_by_idx(imm) means to convert a 32-bit index into an address of a map > +* map_val(map) gets the address of the first value in a given map > +* var_addr(imm) gets the address of a platform variable (see `Platform Variables`_) with a given id > +* code_addr(imm) gets the address of the instruction at a specified relative offset in number of (64-bit) instructions > +* the 'imm type' can be used by disassemblers for display > +* the 'dst type' can be used for verification and JIT compilation purposes > + > +Maps > +~~~~ > + > +Maps are shared memory regions accessible by eBPF programs on some platforms. > +A map can have various semantics as defined in a separate document, and may or may not have a single > +contiguous memory region, but the 'map_val(map)' is currently only defined for maps that do have a single > +contiguous memory region. Reformatted these sections to fit 80 char. And applied.
