Lines Matching +full:- +full:only
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
31 necessary across calls. Note that there is only one eBPF program (== one
32 eBPF main routine) and it cannot call other eBPF functions, it can only
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
107 For practical reasons all eBPF programs have only one argument 'ctx' which is
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.
202 program will terminate quickly and will only call a fixed number of kernel
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
302 BPF_MOV 0xb0 /* eBPF only: mov reg to reg */
303 BPF_ARSH 0xc0 /* eBPF only: sign extending shift right */
304 BPF_END 0xd0 /* eBPF only: endianness conversion */
308 BPF_JA 0x00 /* BPF_JMP only */
313 BPF_JNE 0x50 /* eBPF only: jump != */
314 BPF_JSGT 0x60 /* eBPF only: signed '>' */
315 BPF_JSGE 0x70 /* eBPF only: signed '>=' */
316 BPF_CALL 0x80 /* eBPF BPF_JMP only: function call */
317 BPF_EXIT 0x90 /* eBPF BPF_JMP only: function return */
318 BPF_JLT 0xa0 /* eBPF only: unsigned '<' */
319 BPF_JLE 0xb0 /* eBPF only: unsigned '<=' */
320 BPF_JSLT 0xc0 /* eBPF only: signed '<' */
321 BPF_JSLE 0xd0 /* eBPF only: signed '<=' */
323 So BPF_ADD | BPF_X | BPF_ALU means 32-bit addition in both classic BPF
324 and eBPF. There are only two registers in classic BPF, so it means A += X.
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 */
374 BPF_LEN 0x80 /* classic BPF only, reserved in eBPF */
375 BPF_MSH 0xa0 /* classic BPF only, reserved in eBPF */
376 BPF_ATOMIC 0xc0 /* eBPF only, atomic operations */