Documentation/bpf/classic_vs_extended.rst

12 - Number of registers increase from 2 to 10:
15   new layout extends this to be 10 internal registers and a read-only frame
16   pointer. Since 64-bit CPUs are passing arguments to functions via registers
17   the number of args from eBPF program to in-kernel function is restricted
18   to 5 and one register is used to accept return value from an in-kernel
20   sparcv9/mips64 have 7 - 8 registers for arguments; x86_64 has 6 callee saved
25   64-bit architectures.
27   On 32-bit architectures JIT may map programs that use only 32-bit arithmetic
30   R0 - R5 are scratch registers and eBPF program needs spill/fill them if
33   call predefined in-kernel functions, though.
35 - Register width increases from 32-bit to 64-bit:
37   Still, the semantics of the original 32-bit ALU operations are preserved
38   via 32-bit subregisters. All eBPF registers are 64-bit with 32-bit lower
39   subregisters that zero-extend into 64-bit if they are being written to.
43   32-bit architectures run 64-bit eBPF programs via interpreter.
44   Their JITs may convert BPF programs that only use 32-bit subregisters into
47   Operation is 64-bit, because on 64-bit architectures, pointers are also
48   64-bit wide, and we want to pass 64-bit values in/out of kernel functions,
49   so 32-bit eBPF registers would otherwise require to define register-pair
53   Another reason is the use of atomic 64-bit counters.
55 - Conditional jt/jf targets replaced with jt/fall-through:
59   ``if (cond) jump_true; /* else fall-through */``.
61 - Introduces bpf_call insn and register passing convention for zero overhead
64   Before an in-kernel function call, the eBPF program needs to
67   to in-kernel function. If R1 - R5 registers are mapped to CPU registers
74   After an in-kernel function call, R1 - R5 are reset to unreadable and R0 has
75   a return value of the function. Since R6 - R9 are callee saved, their state
82     u64 f3(u64 a, u64 b) { return a - b; }
103   If f2 is JITed and the pointer stored to ``_f2``. The calls f1 -> f2 -> f3 and
104   returns will be seamless. Without JIT, __bpf_prog_run() interpreter needs to
113   On 64-bit architectures all register map to HW registers one to one. For
118     R0 - rax
119     R1 - rdi
120     R2 - rsi
121     R3 - rdx
122     R4 - rcx
123     R5 - r8
124     R6 - rbx
125     R7 - r13
126     R8 - r14
127     R9 - r15
128     R10 - rbp
131   and rbx, r12 - r15 are callee saved.
133   Then the following eBPF pseudo-program::
156     mov %rbx,-0x228(%rbp)
157     mov %r13,-0x220(%rbp)
172     mov -0x228(%rbp),%rbx
173     mov -0x220(%rbp),%r13
184   In-kernel functions foo() and bar() with prototype: u64 (*)(u64 arg1, u64
188   interpreter. R0-R5 are scratch registers, so eBPF program needs to preserve
198   After the call the registers R1-R5 contain junk values and cannot be read.
199   An in-kernel verifier.rst is used to validate eBPF programs.
204 which helps to do one-to-one mapping between eBPF insn and x86 insn during JIT.
214 So far 87 eBPF instructions were implemented. 8-bit 'op' opcode field
235 can be determined in two steps: first step does depth-first-search to disallow
246 For arithmetic and jump instructions the 8-bit 'code' field is divided into three
249   +----------------+--------+--------------------+
252   +----------------+--------+--------------------+
279 	BPF_SRC(code) == BPF_X - use register X as source operand
280 	BPF_SRC(code) == BPF_K - use 32-bit immediate as source operand
284 	BPF_SRC(code) == BPF_X - use 'src_reg' register as source operand
285 	BPF_SRC(code) == BPF_K - use 32-bit immediate as source operand
323 So BPF_ADD | BPF_X | BPF_ALU means 32-bit addition in both classic BPF
332 exactly the same operations as BPF_ALU, but with 64-bit wide operands
333 instead. So BPF_ADD | BPF_X | BPF_ALU64 means 64-bit addition, i.e.:
339 in eBPF means function exit only. The eBPF program needs to store return
341 BPF_JMP32 to mean exactly the same operations as BPF_JMP, but with 32-bit wide
344 For load and store instructions the 8-bit 'code' field is divided as::
346   +--------+--------+-------------------+
349   +--------+--------+-------------------+
359   BPF_DW  0x18    /* eBPF only, double word */
363  B  - 1 byte
364  H  - 2 byte
365  W  - 4 byte
366  DW - 8 byte (eBPF only)
370   BPF_IMM     0x00  /* used for 32-bit mov in classic BPF and 64-bit in eBPF */