dthaler / ebpf-docs Goto Github PK

https://github.com/dthaler/ebpf-docs/blob/update/isa/kernel.org/instruction-set.rst#jump-instructions
https://github.com/dthaler/ebpf-docs/blob/update/isa/kernel.org/instruction-set.rst#ebpf-functions

BPF call instruction with src == 1 should pass the offset to the BPF function via the immediate field and not the offset field.

Quentin writes:

The dest = imm (0x18) and call (0x85) instructions have a different semantic when their src register is set to a special flag. I think this is also part of the ISA and should be documented? See commits 2 to 7 of iovisor/bpf-docs#26 (and their description) for a quick reference.

The PR has:

0x18 (src == 0) | lddw dst, imm | dst = imm
0x18 (src == 1) | lddw dst, map | dst = imm with imm == map fd
0x18 (src == 2) | lddw dst, map value | dst = map[0] + insn[1].imm with insn[0] == map fd
0x18 (src == 3) | lddw dst, kernel var | dst = imm with imm == BTF id of var
0x18 (src == 4) | lddw dst, BPF func | dst = imm with imm == insn offset of BPF callback
0x18 (src == 5) | lddw dst, imm | dst = imm with imm == map index
0x18 (src == 6) | lddw dst, map value | dst = map[0] + insn[1].imm with insn[0] == map index

But what does "map[0]" mean? What does "insn[0]" mean, is that relative to the PC or absolute from the start of the program or what?
Also the ISA does not currently define the existence / meaning of a "map fd" or a "BTF id of var" or a "map index" or a "BPF callback". I'm concerned about adding these to the ISA without definitions.

Christoph argued on the list that these should be moved out to a separate document.

Leave cpu version numbers to Clang specific implementation notes

Assume:

mov r0, -10

Byte sequence:

b7 00 00 00 f6 f6 ff ff

What value should r0 contain?
0x00000000FFFFFFF6 or 0xFFFFFFFFFFFFFFF6

Should there be a sign extend operation when loading the 32bit immediate value into the 64bit unsigned register?

From: https://lore.kernel.org/bpf/[email protected]/

I think we need to document them as supported in the linux kernel,
but deprecated in general.
The standard might say "implementation defined" meaning that
different run-times don't have to support them.

Yeah. If we do the extensions proposal above we could make these
a specific extension as well.