sphinx.addnodesdocument)}( rawsourcechildren]( translations LanguagesNode)}(hhh](h pending_xref)}(hhh]docutils.nodesTextChinese (Simplified)}parenthsba attributes}(ids]classes]names]dupnames]backrefs] refdomainstdreftypedoc reftarget+/translations/zh_CN/bpf/classic_vs_extendedmodnameN classnameN refexplicitutagnamehhh ubh)}(hhh]hChinese (Traditional)}hh2sbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget+/translations/zh_TW/bpf/classic_vs_extendedmodnameN classnameN refexplicituh1hhh ubh)}(hhh]hItalian}hhFsbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget+/translations/it_IT/bpf/classic_vs_extendedmodnameN classnameN refexplicituh1hhh ubh)}(hhh]hJapanese}hhZsbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget+/translations/ja_JP/bpf/classic_vs_extendedmodnameN classnameN refexplicituh1hhh ubh)}(hhh]hKorean}hhnsbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget+/translations/ko_KR/bpf/classic_vs_extendedmodnameN classnameN refexplicituh1hhh ubh)}(hhh]hPortuguese (Brazilian)}hhsbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget+/translations/pt_BR/bpf/classic_vs_extendedmodnameN classnameN refexplicituh1hhh ubh)}(hhh]hSpanish}hhsbah}(h]h ]h"]h$]h&] refdomainh)reftypeh+ reftarget+/translations/sp_SP/bpf/classic_vs_extendedmodnameN classnameN refexplicituh1hhh ubeh}(h]h ]h"]h$]h&]current_languageEnglishuh1h hh _documenthsourceNlineNubhsection)}(hhh](htitle)}(hClassic BPF vs eBPFh]hClassic BPF vs eBPF}(hhhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhhhE/var/lib/git/docbuild/linux/Documentation/bpf/classic_vs_extended.rsthKubh paragraph)}(heBPF is designed to be JITed with one to one mapping, which can also open up the possibility for GCC/LLVM compilers to generate optimized eBPF code through an eBPF backend that performs almost as fast as natively compiled code.h]heBPF is designed to be JITed with one to one mapping, which can also open up the possibility for GCC/LLVM compilers to generate optimized eBPF code through an eBPF backend that performs almost as fast as natively compiled code.}(hhhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhhhhubh)}(h6Some core changes of the eBPF format from classic BPF:h]h6Some core changes of the eBPF format from classic BPF:}(hhhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK hhhhubh bullet_list)}(hhh](h list_item)}(hXNumber of registers increase from 2 to 10: The old format had two registers A and X, and a hidden frame pointer. The new layout extends this to be 10 internal registers and a read-only frame pointer. Since 64-bit CPUs are passing arguments to functions via registers the number of args from eBPF program to in-kernel function is restricted to 5 and one register is used to accept return value from an in-kernel function. Natively, x86_64 passes first 6 arguments in registers, aarch64/ sparcv9/mips64 have 7 - 8 registers for arguments; x86_64 has 6 callee saved registers, and aarch64/sparcv9/mips64 have 11 or more callee saved registers. Thus, all eBPF registers map one to one to HW registers on x86_64, aarch64, etc, and eBPF calling convention maps directly to ABIs used by the kernel on 64-bit architectures. On 32-bit architectures JIT may map programs that use only 32-bit arithmetic and may let more complex programs to be interpreted. R0 - R5 are scratch registers and eBPF program needs spill/fill them if necessary across calls. Note that there is only one eBPF program (== one eBPF main routine) and it cannot call other eBPF functions, it can only call predefined in-kernel functions, though. h](h)}(h*Number of registers increase from 2 to 10:h]h*Number of registers increase from 2 to 10:}(hhhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK hhubh)}(hXUThe old format had two registers A and X, and a hidden frame pointer. The new layout extends this to be 10 internal registers and a read-only frame pointer. Since 64-bit CPUs are passing arguments to functions via registers the number of args from eBPF program to in-kernel function is restricted to 5 and one register is used to accept return value from an in-kernel function. Natively, x86_64 passes first 6 arguments in registers, aarch64/ sparcv9/mips64 have 7 - 8 registers for arguments; x86_64 has 6 callee saved registers, and aarch64/sparcv9/mips64 have 11 or more callee saved registers.h]hXUThe old format had two registers A and X, and a hidden frame pointer. The new layout extends this to be 10 internal registers and a read-only frame pointer. Since 64-bit CPUs are passing arguments to functions via registers the number of args from eBPF program to in-kernel function is restricted to 5 and one register is used to accept return value from an in-kernel function. Natively, x86_64 passes first 6 arguments in registers, aarch64/ sparcv9/mips64 have 7 - 8 registers for arguments; x86_64 has 6 callee saved registers, and aarch64/sparcv9/mips64 have 11 or more callee saved registers.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhhubh)}(hThus, all eBPF registers map one to one to HW registers on x86_64, aarch64, etc, and eBPF calling convention maps directly to ABIs used by the kernel on 64-bit architectures.h]hThus, all eBPF registers map one to one to HW registers on x86_64, aarch64, etc, and eBPF calling convention maps directly to ABIs used by the kernel on 64-bit architectures.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhhubh)}(hOn 32-bit architectures JIT may map programs that use only 32-bit arithmetic and may let more complex programs to be interpreted.h]hOn 32-bit architectures JIT may map programs that use only 32-bit arithmetic and may let more complex programs to be interpreted.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhhubh)}(hXR0 - R5 are scratch registers and eBPF program needs spill/fill them if necessary across calls. Note that there is only one eBPF program (== one eBPF main routine) and it cannot call other eBPF functions, it can only call predefined in-kernel functions, though.h]hXR0 - R5 are scratch registers and eBPF program needs spill/fill them if necessary across calls. Note that there is only one eBPF program (== one eBPF main routine) and it cannot call other eBPF functions, it can only call predefined in-kernel functions, though.}(hj,hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhhubeh}(h]h ]h"]h$]h&]uh1hhhhhhhhNubh)}(hX0Register width increases from 32-bit to 64-bit: Still, the semantics of the original 32-bit ALU operations are preserved via 32-bit subregisters. All eBPF registers are 64-bit with 32-bit lower subregisters that zero-extend into 64-bit if they are being written to. That behavior maps directly to x86_64 and arm64 subregister definition, but makes other JITs more difficult. 32-bit architectures run 64-bit eBPF programs via interpreter. Their JITs may convert BPF programs that only use 32-bit subregisters into native instruction set and let the rest being interpreted. Operation is 64-bit, because on 64-bit architectures, pointers are also 64-bit wide, and we want to pass 64-bit values in/out of kernel functions, so 32-bit eBPF registers would otherwise require to define register-pair ABI, thus, there won't be able to use a direct eBPF register to HW register mapping and JIT would need to do combine/split/move operations for every register in and out of the function, which is complex, bug prone and slow. Another reason is the use of atomic 64-bit counters. h](h)}(h/Register width increases from 32-bit to 64-bit:h]h/Register width increases from 32-bit to 64-bit:}(hjDhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK#hj@ubh)}(hXFStill, the semantics of the original 32-bit ALU operations are preserved via 32-bit subregisters. All eBPF registers are 64-bit with 32-bit lower subregisters that zero-extend into 64-bit if they are being written to. That behavior maps directly to x86_64 and arm64 subregister definition, but makes other JITs more difficult.h]hXFStill, the semantics of the original 32-bit ALU operations are preserved via 32-bit subregisters. All eBPF registers are 64-bit with 32-bit lower subregisters that zero-extend into 64-bit if they are being written to. That behavior maps directly to x86_64 and arm64 subregister definition, but makes other JITs more difficult.}(hjRhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK%hj@ubh)}(h32-bit architectures run 64-bit eBPF programs via interpreter. Their JITs may convert BPF programs that only use 32-bit subregisters into native instruction set and let the rest being interpreted.h]h32-bit architectures run 64-bit eBPF programs via interpreter. Their JITs may convert BPF programs that only use 32-bit subregisters into native instruction set and let the rest being interpreted.}(hj`hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK+hj@ubh)}(hXOperation is 64-bit, because on 64-bit architectures, pointers are also 64-bit wide, and we want to pass 64-bit values in/out of kernel functions, so 32-bit eBPF registers would otherwise require to define register-pair ABI, thus, there won't be able to use a direct eBPF register to HW register mapping and JIT would need to do combine/split/move operations for every register in and out of the function, which is complex, bug prone and slow. Another reason is the use of atomic 64-bit counters.h]hXOperation is 64-bit, because on 64-bit architectures, pointers are also 64-bit wide, and we want to pass 64-bit values in/out of kernel functions, so 32-bit eBPF registers would otherwise require to define register-pair ABI, thus, there won’t be able to use a direct eBPF register to HW register mapping and JIT would need to do combine/split/move operations for every register in and out of the function, which is complex, bug prone and slow. Another reason is the use of atomic 64-bit counters.}(hjnhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK/hj@ubeh}(h]h ]h"]h$]h&]uh1hhhhhhhhNubh)}(hXConditional jt/jf targets replaced with jt/fall-through: While the original design has constructs such as ``if (cond) jump_true; else jump_false;``, they are being replaced into alternative constructs like ``if (cond) jump_true; /* else fall-through */``. h](h)}(h8Conditional jt/jf targets replaced with jt/fall-through:h]h8Conditional jt/jf targets replaced with jt/fall-through:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK7hjubh)}(hWhile the original design has constructs such as ``if (cond) jump_true; else jump_false;``, they are being replaced into alternative constructs like ``if (cond) jump_true; /* else fall-through */``.h](h1While the original design has constructs such as }(hjhhhNhNubhliteral)}(h)``if (cond) jump_true; else jump_false;``h]h%if (cond) jump_true; else jump_false;}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1jhjubh;, they are being replaced into alternative constructs like }(hjhhhNhNubj)}(h0``if (cond) jump_true; /* else fall-through */``h]h,if (cond) jump_true; /* else fall-through */}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1jhjubh.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhK9hjubeh}(h]h ]h"]h$]h&]uh1hhhhhhhhNubh)}(hXIntroduces bpf_call insn and register passing convention for zero overhead calls from/to other kernel functions: Before an in-kernel function call, the eBPF program needs to place function arguments into R1 to R5 registers to satisfy calling convention, then the interpreter will take them from registers and pass to in-kernel function. If R1 - R5 registers are mapped to CPU registers that are used for argument passing on given architecture, the JIT compiler doesn't need to emit extra moves. Function arguments will be in the correct registers and BPF_CALL instruction will be JITed as single 'call' HW instruction. This calling convention was picked to cover common call situations without performance penalty. After an in-kernel function call, R1 - R5 are reset to unreadable and R0 has a return value of the function. Since R6 - R9 are callee saved, their state is preserved across the call. For example, consider three C functions:: u64 f1() { return (*_f2)(1); } u64 f2(u64 a) { return f3(a + 1, a); } u64 f3(u64 a, u64 b) { return a - b; } GCC can compile f1, f3 into x86_64:: f1: movl $1, %edi movq _f2(%rip), %rax jmp *%rax f3: movq %rdi, %rax subq %rsi, %rax ret Function f2 in eBPF may look like:: f2: bpf_mov R2, R1 bpf_add R1, 1 bpf_call f3 bpf_exit If f2 is JITed and the pointer stored to ``_f2``. The calls f1 -> f2 -> f3 and returns will be seamless. Without JIT, __bpf_prog_run() interpreter needs to be used to call into f2. For practical reasons all eBPF programs have only one argument 'ctx' which is already placed into R1 (e.g. on __bpf_prog_run() startup) and the programs can call kernel functions with up to 5 arguments. Calls with 6 or more arguments are currently not supported, but these restrictions can be lifted if necessary in the future. On 64-bit architectures all register map to HW registers one to one. For example, x86_64 JIT compiler can map them as ... :: R0 - rax R1 - rdi R2 - rsi R3 - rdx R4 - rcx R5 - r8 R6 - rbx R7 - r13 R8 - r14 R9 - r15 R10 - rbp ... since x86_64 ABI mandates rdi, rsi, rdx, rcx, r8, r9 for argument passing and rbx, r12 - r15 are callee saved. Then the following eBPF pseudo-program:: bpf_mov R6, R1 /* save ctx */ bpf_mov R2, 2 bpf_mov R3, 3 bpf_mov R4, 4 bpf_mov R5, 5 bpf_call foo bpf_mov R7, R0 /* save foo() return value */ bpf_mov R1, R6 /* restore ctx for next call */ bpf_mov R2, 6 bpf_mov R3, 7 bpf_mov R4, 8 bpf_mov R5, 9 bpf_call bar bpf_add R0, R7 bpf_exit After JIT to x86_64 may look like:: push %rbp mov %rsp,%rbp sub $0x228,%rsp mov %rbx,-0x228(%rbp) mov %r13,-0x220(%rbp) mov %rdi,%rbx mov $0x2,%esi mov $0x3,%edx mov $0x4,%ecx mov $0x5,%r8d callq foo mov %rax,%r13 mov %rbx,%rdi mov $0x6,%esi mov $0x7,%edx mov $0x8,%ecx mov $0x9,%r8d callq bar add %r13,%rax mov -0x228(%rbp),%rbx mov -0x220(%rbp),%r13 leaveq retq Which is in this example equivalent in C to:: u64 bpf_filter(u64 ctx) { return foo(ctx, 2, 3, 4, 5) + bar(ctx, 6, 7, 8, 9); } In-kernel functions foo() and bar() with prototype: u64 (*)(u64 arg1, u64 arg2, u64 arg3, u64 arg4, u64 arg5); will receive arguments in proper registers and place their return value into ``%rax`` which is R0 in eBPF. Prologue and epilogue are emitted by JIT and are implicit in the interpreter. R0-R5 are scratch registers, so eBPF program needs to preserve them across the calls as defined by calling convention. For example the following program is invalid:: bpf_mov R1, 1 bpf_call foo bpf_mov R0, R1 bpf_exit After the call the registers R1-R5 contain junk values and cannot be read. An in-kernel verifier.rst is used to validate eBPF programs. h](h)}(hpIntroduces bpf_call insn and register passing convention for zero overhead calls from/to other kernel functions:h]hpIntroduces bpf_call insn and register passing convention for zero overhead calls from/to other kernel functions:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK=hjubh)}(hXYBefore an in-kernel function call, the eBPF program needs to place function arguments into R1 to R5 registers to satisfy calling convention, then the interpreter will take them from registers and pass to in-kernel function. If R1 - R5 registers are mapped to CPU registers that are used for argument passing on given architecture, the JIT compiler doesn't need to emit extra moves. Function arguments will be in the correct registers and BPF_CALL instruction will be JITed as single 'call' HW instruction. This calling convention was picked to cover common call situations without performance penalty.h]hX_Before an in-kernel function call, the eBPF program needs to place function arguments into R1 to R5 registers to satisfy calling convention, then the interpreter will take them from registers and pass to in-kernel function. If R1 - R5 registers are mapped to CPU registers that are used for argument passing on given architecture, the JIT compiler doesn’t need to emit extra moves. Function arguments will be in the correct registers and BPF_CALL instruction will be JITed as single ‘call’ HW instruction. This calling convention was picked to cover common call situations without performance penalty.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK@hjubh)}(hAfter an in-kernel function call, R1 - R5 are reset to unreadable and R0 has a return value of the function. Since R6 - R9 are callee saved, their state is preserved across the call.h]hAfter an in-kernel function call, R1 - R5 are reset to unreadable and R0 has a return value of the function. Since R6 - R9 are callee saved, their state is preserved across the call.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKJhjubh)}(h)For example, consider three C functions::h]h(For example, consider three C functions:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKNhjubh literal_block)}(hlu64 f1() { return (*_f2)(1); } u64 f2(u64 a) { return f3(a + 1, a); } u64 f3(u64 a, u64 b) { return a - b; }h]hlu64 f1() { return (*_f2)(1); } u64 f2(u64 a) { return f3(a + 1, a); } u64 f3(u64 a, u64 b) { return a - b; }}hj sbah}(h]h ]h"]h$]h&] xml:spacepreserveuh1j hhhKPhjubh)}(h$GCC can compile f1, f3 into x86_64::h]h#GCC can compile f1, f3 into x86_64:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKThjubj )}(hqf1: movl $1, %edi movq _f2(%rip), %rax jmp *%rax f3: movq %rdi, %rax subq %rsi, %rax reth]hqf1: movl $1, %edi movq _f2(%rip), %rax jmp *%rax f3: movq %rdi, %rax subq %rsi, %rax ret}hj*sbah}(h]h ]h"]h$]h&]jjuh1j hhhKVhjubh)}(h#Function f2 in eBPF may look like::h]h"Function f2 in eBPF may look like:}(hj8hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhK_hjubj )}(hEf2: bpf_mov R2, R1 bpf_add R1, 1 bpf_call f3 bpf_exith]hEf2: bpf_mov R2, R1 bpf_add R1, 1 bpf_call f3 bpf_exit}hjFsbah}(h]h ]h"]h$]h&]jjuh1j hhhKahjubh)}(hIf f2 is JITed and the pointer stored to ``_f2``. The calls f1 -> f2 -> f3 and returns will be seamless. Without JIT, __bpf_prog_run() interpreter needs to be used to call into f2.h](h)If f2 is JITed and the pointer stored to }(hjThhhNhNubj)}(h``_f2``h]h_f2}(hj\hhhNhNubah}(h]h ]h"]h$]h&]uh1jhjTubh. The calls f1 -> f2 -> f3 and returns will be seamless. Without JIT, __bpf_prog_run() interpreter needs to be used to call into f2.}(hjThhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKghjubh)}(hXGFor practical reasons all eBPF programs have only one argument 'ctx' which is already placed into R1 (e.g. on __bpf_prog_run() startup) and the programs can call kernel functions with up to 5 arguments. Calls with 6 or more arguments are currently not supported, but these restrictions can be lifted if necessary in the future.h]hXKFor practical reasons all eBPF programs have only one argument ‘ctx’ which is already placed into R1 (e.g. on __bpf_prog_run() startup) and the programs can call kernel functions with up to 5 arguments. Calls with 6 or more arguments are currently not supported, but these restrictions can be lifted if necessary in the future.}(hjthhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKkhjubh)}(hyOn 64-bit architectures all register map to HW registers one to one. For example, x86_64 JIT compiler can map them as ...h]hyOn 64-bit architectures all register map to HW registers one to one. For example, x86_64 JIT compiler can map them as ...}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKqhjubj )}(hbR0 - rax R1 - rdi R2 - rsi R3 - rdx R4 - rcx R5 - r8 R6 - rbx R7 - r13 R8 - r14 R9 - r15 R10 - rbph]hbR0 - rax R1 - rdi R2 - rsi R3 - rdx R4 - rcx R5 - r8 R6 - rbx R7 - r13 R8 - r14 R9 - r15 R10 - rbp}hjsbah}(h]h ]h"]h$]h&]jjuh1j hhhKvhjubh)}(hr... since x86_64 ABI mandates rdi, rsi, rdx, rcx, r8, r9 for argument passing and rbx, r12 - r15 are callee saved.h]hr... since x86_64 ABI mandates rdi, rsi, rdx, rcx, r8, r9 for argument passing and rbx, r12 - r15 are callee saved.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjubh)}(h(Then the following eBPF pseudo-program::h]h'Then the following eBPF pseudo-program:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjubj )}(hXbpf_mov R6, R1 /* save ctx */ bpf_mov R2, 2 bpf_mov R3, 3 bpf_mov R4, 4 bpf_mov R5, 5 bpf_call foo bpf_mov R7, R0 /* save foo() return value */ bpf_mov R1, R6 /* restore ctx for next call */ bpf_mov R2, 6 bpf_mov R3, 7 bpf_mov R4, 8 bpf_mov R5, 9 bpf_call bar bpf_add R0, R7 bpf_exith]hXbpf_mov R6, R1 /* save ctx */ bpf_mov R2, 2 bpf_mov R3, 3 bpf_mov R4, 4 bpf_mov R5, 5 bpf_call foo bpf_mov R7, R0 /* save foo() return value */ bpf_mov R1, R6 /* restore ctx for next call */ bpf_mov R2, 6 bpf_mov R3, 7 bpf_mov R4, 8 bpf_mov R5, 9 bpf_call bar bpf_add R0, R7 bpf_exit}hjsbah}(h]h ]h"]h$]h&]jjuh1j hhhKhjubh)}(h#After JIT to x86_64 may look like::h]h"After JIT to x86_64 may look like:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjubj )}(hXGpush %rbp mov %rsp,%rbp sub $0x228,%rsp mov %rbx,-0x228(%rbp) mov %r13,-0x220(%rbp) mov %rdi,%rbx mov $0x2,%esi mov $0x3,%edx mov $0x4,%ecx mov $0x5,%r8d callq foo mov %rax,%r13 mov %rbx,%rdi mov $0x6,%esi mov $0x7,%edx mov $0x8,%ecx mov $0x9,%r8d callq bar add %r13,%rax mov -0x228(%rbp),%rbx mov -0x220(%rbp),%r13 leaveq retqh]hXGpush %rbp mov %rsp,%rbp sub $0x228,%rsp mov %rbx,-0x228(%rbp) mov %r13,-0x220(%rbp) mov %rdi,%rbx mov $0x2,%esi mov $0x3,%edx mov $0x4,%ecx mov $0x5,%r8d callq foo mov %rax,%r13 mov %rbx,%rdi mov $0x6,%esi mov $0x7,%edx mov $0x8,%ecx mov $0x9,%r8d callq bar add %r13,%rax mov -0x228(%rbp),%rbx mov -0x220(%rbp),%r13 leaveq retq}hjsbah}(h]h ]h"]h$]h&]jjuh1j hhhKhjubh)}(h-Which is in this example equivalent in C to::h]h,Which is in this example equivalent in C to:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjubj )}(hSu64 bpf_filter(u64 ctx) { return foo(ctx, 2, 3, 4, 5) + bar(ctx, 6, 7, 8, 9); }h]hSu64 bpf_filter(u64 ctx) { return foo(ctx, 2, 3, 4, 5) + bar(ctx, 6, 7, 8, 9); }}hjsbah}(h]h ]h"]h$]h&]jjuh1j hhhKhjubh)}(hXIn-kernel functions foo() and bar() with prototype: u64 (*)(u64 arg1, u64 arg2, u64 arg3, u64 arg4, u64 arg5); will receive arguments in proper registers and place their return value into ``%rax`` which is R0 in eBPF. Prologue and epilogue are emitted by JIT and are implicit in the interpreter. R0-R5 are scratch registers, so eBPF program needs to preserve them across the calls as defined by calling convention.h](hIn-kernel functions foo() and bar() with prototype: u64 (*)(u64 arg1, u64 arg2, u64 arg3, u64 arg4, u64 arg5); will receive arguments in proper registers and place their return value into }(hjhhhNhNubj)}(h``%rax``h]h%rax}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1jhjubh which is R0 in eBPF. Prologue and epilogue are emitted by JIT and are implicit in the interpreter. R0-R5 are scratch registers, so eBPF program needs to preserve them across the calls as defined by calling convention.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKhjubh)}(h.For example the following program is invalid::h]h-For example the following program is invalid:}(hj hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjubj )}(h2bpf_mov R1, 1 bpf_call foo bpf_mov R0, R1 bpf_exith]h2bpf_mov R1, 1 bpf_call foo bpf_mov R0, R1 bpf_exit}hj.sbah}(h]h ]h"]h$]h&]jjuh1j hhhKhjubh)}(hAfter the call the registers R1-R5 contain junk values and cannot be read. An in-kernel verifier.rst is used to validate eBPF programs.h]hAfter the call the registers R1-R5 contain junk values and cannot be read. An in-kernel verifier.rst is used to validate eBPF programs.}(hj<hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjubeh}(h]h ]h"]h$]h&]uh1hhhhhhhhNubeh}(h]h ]h"]h$]h&]bullet-uh1hhhhK hhhhubh)}(hX%Also in the new design, eBPF is limited to 4096 insns, which means that any program will terminate quickly and will only call a fixed number of kernel functions. Original BPF and eBPF are two operand instructions, which helps to do one-to-one mapping between eBPF insn and x86 insn during JIT.h]hX%Also in the new design, eBPF is limited to 4096 insns, which means that any program will terminate quickly and will only call a fixed number of kernel functions. Original BPF and eBPF are two operand instructions, which helps to do one-to-one mapping between eBPF insn and x86 insn during JIT.}(hjXhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhhhhubh)}(hThe input context pointer for invoking the interpreter function is generic, its content is defined by a specific use case. For seccomp register R1 points to seccomp_data, for converted BPF filters R1 points to a skb.h]hThe input context pointer for invoking the interpreter function is generic, its content is defined by a specific use case. For seccomp register R1 points to seccomp_data, for converted BPF filters R1 points to a skb.}(hjfhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhhhhubh)}(hMA program, that is translated internally consists of the following elements::h]hLA program, that is translated internally consists of the following elements:}(hjthhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhhhhubj )}(hLop:16, jt:8, jf:8, k:32 ==> op:8, dst_reg:4, src_reg:4, off:16, imm:32h]hLop:16, jt:8, jf:8, k:32 ==> op:8, dst_reg:4, src_reg:4, off:16, imm:32}hjsbah}(h]h ]h"]h$]h&]jjuh1j hhhKhhhhubh)}(hSo far 87 eBPF instructions were implemented. 8-bit 'op' opcode field has room for new instructions. Some of them may use 16/24/32 byte encoding. New instructions must be multiple of 8 bytes to preserve backward compatibility.h]hSo far 87 eBPF instructions were implemented. 8-bit ‘op’ opcode field has room for new instructions. Some of them may use 16/24/32 byte encoding. New instructions must be multiple of 8 bytes to preserve backward compatibility.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhhhhubh)}(hXeBPF is a general purpose RISC instruction set. Not every register and every instruction are used during translation from original BPF to eBPF. For example, socket filters are not using ``exclusive add`` instruction, but tracing filters may do to maintain counters of events, for example. Register R9 is not used by socket filters either, but more complex filters may be running out of registers and would have to resort to spill/fill to stack.h](heBPF is a general purpose RISC instruction set. Not every register and every instruction are used during translation from original BPF to eBPF. For example, socket filters are not using }(hjhhhNhNubj)}(h``exclusive add``h]h exclusive add}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1jhjubh instruction, but tracing filters may do to maintain counters of events, for example. Register R9 is not used by socket filters either, but more complex filters may be running out of registers and would have to resort to spill/fill to stack.}(hjhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhKhhhhubh)}(hXeBPF can be used as a generic assembler for last step performance optimizations, socket filters and seccomp are using it as assembler. Tracing filters may use it as assembler to generate code from kernel. In kernel usage may not be bounded by security considerations, since generated eBPF code may be optimizing internal code path and not being exposed to the user space. Safety of eBPF can come from the verifier.rst. In such use cases as described, it may be used as safe instruction set.h]hXeBPF can be used as a generic assembler for last step performance optimizations, socket filters and seccomp are using it as assembler. Tracing filters may use it as assembler to generate code from kernel. In kernel usage may not be bounded by security considerations, since generated eBPF code may be optimizing internal code path and not being exposed to the user space. Safety of eBPF can come from the verifier.rst. In such use cases as described, it may be used as safe instruction set.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhhhhubh)}(hXJust like the original BPF, eBPF runs within a controlled environment, is deterministic and the kernel can easily prove that. The safety of the program can be determined in two steps: first step does depth-first-search to disallow loops and other CFG validation; second step starts from the first insn and descends all possible paths. It simulates execution of every insn and observes the state change of registers and stack.h]hXJust like the original BPF, eBPF runs within a controlled environment, is deterministic and the kernel can easily prove that. The safety of the program can be determined in two steps: first step does depth-first-search to disallow loops and other CFG validation; second step starts from the first insn and descends all possible paths. It simulates execution of every insn and observes the state change of registers and stack.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhhhhubh)}(hhh](h)}(hopcode encodingh]hopcode encoding}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhjhhhhhKubh)}(hgeBPF is reusing most of the opcode encoding from classic to simplify conversion of classic BPF to eBPF.h]hgeBPF is reusing most of the opcode encoding from classic to simplify conversion of classic BPF to eBPF.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjhhubh)}(hYFor arithmetic and jump instructions the 8-bit 'code' field is divided into three parts::h]h\For arithmetic and jump instructions the 8-bit ‘code’ field is divided into three parts:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjhhubj )}(h+----------------+--------+--------------------+ | 4 bits | 1 bit | 3 bits | | operation code | source | instruction class | +----------------+--------+--------------------+ (MSB) (LSB)h]h+----------------+--------+--------------------+ | 4 bits | 1 bit | 3 bits | | operation code | source | instruction class | +----------------+--------+--------------------+ (MSB) (LSB)}hjsbah}(h]h ]h"]h$]h&]jjuh1j hhhKhjhhubh)}(h7Three LSB bits store instruction class which is one of:h]h7Three LSB bits store instruction class which is one of:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhKhjhhubh block_quote)}(hX=================== =============== Classic BPF classes eBPF classes =================== =============== BPF_LD 0x00 BPF_LD 0x00 BPF_LDX 0x01 BPF_LDX 0x01 BPF_ST 0x02 BPF_ST 0x02 BPF_STX 0x03 BPF_STX 0x03 BPF_ALU 0x04 BPF_ALU 0x04 BPF_JMP 0x05 BPF_JMP 0x05 BPF_RET 0x06 BPF_JMP32 0x06 BPF_MISC 0x07 BPF_ALU64 0x07 =================== =============== h]htable)}(hhh]htgroup)}(hhh](hcolspec)}(hhh]h}(h]h ]h"]h$]h&]colwidthKuh1j3hj0ubj4)}(hhh]h}(h]h ]h"]h$]h&]colwidthKuh1j3hj0ubhthead)}(hhh]hrow)}(hhh](hentry)}(hhh]h)}(hClassic BPF classesh]hClassic BPF classes}(hjXhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjUubah}(h]h ]h"]h$]h&]uh1jShjPubjT)}(hhh]h)}(h eBPF classesh]h eBPF classes}(hjohhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjlubah}(h]h ]h"]h$]h&]uh1jShjPubeh}(h]h ]h"]h$]h&]uh1jNhjKubah}(h]h ]h"]h$]h&]uh1jIhj0ubhtbody)}(hhh](jO)}(hhh](jT)}(hhh]h)}(hBPF_LD 0x00h]hBPF_LD 0x00}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1jShjubjT)}(hhh]h)}(hBPF_LD 0x00h]hBPF_LD 0x00}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1jShjubeh}(h]h ]h"]h$]h&]uh1jNhjubjO)}(hhh](jT)}(hhh]h)}(hBPF_LDX 0x01h]hBPF_LDX 0x01}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1jShjubjT)}(hhh]h)}(hBPF_LDX 0x01h]hBPF_LDX 0x01}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1jShjubeh}(h]h ]h"]h$]h&]uh1jNhjubjO)}(hhh](jT)}(hhh]h)}(hBPF_ST 0x02h]hBPF_ST 0x02}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1jShjubjT)}(hhh]h)}(hBPF_ST 0x02h]hBPF_ST 0x02}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1jShjubeh}(h]h ]h"]h$]h&]uh1jNhjubjO)}(hhh](jT)}(hhh]h)}(hBPF_STX 0x03h]hBPF_STX 0x03}(hj?hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhj<ubah}(h]h ]h"]h$]h&]uh1jShj9ubjT)}(hhh]h)}(hBPF_STX 0x03h]hBPF_STX 0x03}(hjVhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjSubah}(h]h ]h"]h$]h&]uh1jShj9ubeh}(h]h ]h"]h$]h&]uh1jNhjubjO)}(hhh](jT)}(hhh]h)}(hBPF_ALU 0x04h]hBPF_ALU 0x04}(hjvhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjsubah}(h]h ]h"]h$]h&]uh1jShjpubjT)}(hhh]h)}(hBPF_ALU 0x04h]hBPF_ALU 0x04}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubah}(h]h ]h"]h$]h&]uh1jShjpubeh}(h]h ]h"]h$]h&]uh1jNhjubjO)}(hhh](jT)}(hhh]h)}(hBPF_JMP 0x05h]hBPF_JMP 0x05}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM hjubah}(h]h ]h"]h$]h&]uh1jShjubjT)}(hhh]h)}(hBPF_JMP 0x05h]hBPF_JMP 0x05}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM hjubah}(h]h ]h"]h$]h&]uh1jShjubeh}(h]h ]h"]h$]h&]uh1jNhjubjO)}(hhh](jT)}(hhh]h)}(hBPF_RET 0x06h]hBPF_RET 0x06}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM hjubah}(h]h ]h"]h$]h&]uh1jShjubjT)}(hhh]h)}(hBPF_JMP32 0x06h]hBPF_JMP32 0x06}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM hjubah}(h]h ]h"]h$]h&]uh1jShjubeh}(h]h ]h"]h$]h&]uh1jNhjubjO)}(hhh](jT)}(hhh]h)}(hBPF_MISC 0x07h]hBPF_MISC 0x07}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM hjubah}(h]h ]h"]h$]h&]uh1jShjubjT)}(hhh]h)}(hBPF_ALU64 0x07h]hBPF_ALU64 0x07}(hj2hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM hj/ubah}(h]h ]h"]h$]h&]uh1jShjubeh}(h]h ]h"]h$]h&]uh1jNhjubeh}(h]h ]h"]h$]h&]uh1jhj0ubeh}(h]h ]h"]h$]h&]colsKuh1j.hj+ubah}(h]h ]h"]h$]h&]uh1j)hj%ubah}(h]h ]h"]h$]h&]uh1j#hhhMhjhhubh)}(h*The 4th bit encodes the source operand ...h]h*The 4th bit encodes the source operand ...}(hjehhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubj$)}(hX :: BPF_K 0x00 BPF_X 0x08 * in classic BPF, this means:: BPF_SRC(code) == BPF_X - use register X as source operand BPF_SRC(code) == BPF_K - use 32-bit immediate as source operand * in eBPF, this means:: BPF_SRC(code) == BPF_X - use 'src_reg' register as source operand BPF_SRC(code) == BPF_K - use 32-bit immediate as source operand h](j$)}(h*:: BPF_K 0x00 BPF_X 0x08 h]j )}(hBPF_K 0x00 BPF_X 0x08h]hBPF_K 0x00 BPF_X 0x08}hj{sbah}(h]h ]h"]h$]h&]jjuh1j hhhMhjwubah}(h]h ]h"]h$]h&]uh1j#hhhMhjsubh)}(hhh](h)}(hin classic BPF, this means:: BPF_SRC(code) == BPF_X - use register X as source operand BPF_SRC(code) == BPF_K - use 32-bit immediate as source operand h](h)}(hin classic BPF, this means::h]hin classic BPF, this means:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubj )}(hyBPF_SRC(code) == BPF_X - use register X as source operand BPF_SRC(code) == BPF_K - use 32-bit immediate as source operandh]hyBPF_SRC(code) == BPF_X - use register X as source operand BPF_SRC(code) == BPF_K - use 32-bit immediate as source operand}hjsbah}(h]h ]h"]h$]h&]jjuh1j hhhMhjubeh}(h]h ]h"]h$]h&]uh1hhjubh)}(hin eBPF, this means:: BPF_SRC(code) == BPF_X - use 'src_reg' register as source operand BPF_SRC(code) == BPF_K - use 32-bit immediate as source operand h](h)}(hin eBPF, this means::h]hin eBPF, this means:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjubj )}(hBPF_SRC(code) == BPF_X - use 'src_reg' register as source operand BPF_SRC(code) == BPF_K - use 32-bit immediate as source operandh]hBPF_SRC(code) == BPF_X - use 'src_reg' register as source operand BPF_SRC(code) == BPF_K - use 32-bit immediate as source operand}hjsbah}(h]h ]h"]h$]h&]jjuh1j hhhMhjubeh}(h]h ]h"]h$]h&]uh1hhjubeh}(h]h ]h"]h$]h&]jV*uh1hhhhMhjsubeh}(h]h ]h"]h$]h&]uh1j#hhhMhjhhubh)}(h+... and four MSB bits store operation code.h]h+... and four MSB bits store operation code.}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMhjhhubh)}(hPIf BPF_CLASS(code) == BPF_ALU or BPF_ALU64 [ in eBPF ], BPF_OP(code) is one of::h]hOIf BPF_CLASS(code) == BPF_ALU or BPF_ALU64 [ in eBPF ], BPF_OP(code) is one of:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM!hjhhubj )}(hXGBPF_ADD 0x00 BPF_SUB 0x10 BPF_MUL 0x20 BPF_DIV 0x30 BPF_OR 0x40 BPF_AND 0x50 BPF_LSH 0x60 BPF_RSH 0x70 BPF_NEG 0x80 BPF_MOD 0x90 BPF_XOR 0xa0 BPF_MOV 0xb0 /* eBPF only: mov reg to reg */ BPF_ARSH 0xc0 /* eBPF only: sign extending shift right */ BPF_END 0xd0 /* eBPF only: endianness conversion */h]hXGBPF_ADD 0x00 BPF_SUB 0x10 BPF_MUL 0x20 BPF_DIV 0x30 BPF_OR 0x40 BPF_AND 0x50 BPF_LSH 0x60 BPF_RSH 0x70 BPF_NEG 0x80 BPF_MOD 0x90 BPF_XOR 0xa0 BPF_MOV 0xb0 /* eBPF only: mov reg to reg */ BPF_ARSH 0xc0 /* eBPF only: sign extending shift right */ BPF_END 0xd0 /* eBPF only: endianness conversion */}hjsbah}(h]h ]h"]h$]h&]jjuh1j hhhM#hjhhubh)}(hPIf BPF_CLASS(code) == BPF_JMP or BPF_JMP32 [ in eBPF ], BPF_OP(code) is one of::h]hOIf BPF_CLASS(code) == BPF_JMP or BPF_JMP32 [ in eBPF ], BPF_OP(code) is one of:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM2hjhhubj )}(hXBPF_JA 0x00 /* BPF_JMP only */ BPF_JEQ 0x10 BPF_JGT 0x20 BPF_JGE 0x30 BPF_JSET 0x40 BPF_JNE 0x50 /* eBPF only: jump != */ BPF_JSGT 0x60 /* eBPF only: signed '>' */ BPF_JSGE 0x70 /* eBPF only: signed '>=' */ BPF_CALL 0x80 /* eBPF BPF_JMP only: function call */ BPF_EXIT 0x90 /* eBPF BPF_JMP only: function return */ BPF_JLT 0xa0 /* eBPF only: unsigned '<' */ BPF_JLE 0xb0 /* eBPF only: unsigned '<=' */ BPF_JSLT 0xc0 /* eBPF only: signed '<' */ BPF_JSLE 0xd0 /* eBPF only: signed '<=' */h]hXBPF_JA 0x00 /* BPF_JMP only */ BPF_JEQ 0x10 BPF_JGT 0x20 BPF_JGE 0x30 BPF_JSET 0x40 BPF_JNE 0x50 /* eBPF only: jump != */ BPF_JSGT 0x60 /* eBPF only: signed '>' */ BPF_JSGE 0x70 /* eBPF only: signed '>=' */ BPF_CALL 0x80 /* eBPF BPF_JMP only: function call */ BPF_EXIT 0x90 /* eBPF BPF_JMP only: function return */ BPF_JLT 0xa0 /* eBPF only: unsigned '<' */ BPF_JLE 0xb0 /* eBPF only: unsigned '<=' */ BPF_JSLT 0xc0 /* eBPF only: signed '<' */ BPF_JSLE 0xd0 /* eBPF only: signed '<=' */}hj#sbah}(h]h ]h"]h$]h&]jjuh1j hhhM4hjhhubh)}(hXMSo BPF_ADD | BPF_X | BPF_ALU means 32-bit addition in both classic BPF and eBPF. There are only two registers in classic BPF, so it means A += X. In eBPF it means dst_reg = (u32) dst_reg + (u32) src_reg; similarly, BPF_XOR | BPF_K | BPF_ALU means A ^= imm32 in classic BPF and analogous src_reg = (u32) src_reg ^ (u32) imm32 in eBPF.h]hXMSo BPF_ADD | BPF_X | BPF_ALU means 32-bit addition in both classic BPF and eBPF. There are only two registers in classic BPF, so it means A += X. In eBPF it means dst_reg = (u32) dst_reg + (u32) src_reg; similarly, BPF_XOR | BPF_K | BPF_ALU means A ^= imm32 in classic BPF and analogous src_reg = (u32) src_reg ^ (u32) imm32 in eBPF.}(hj1hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMChjhhubh)}(hX}Classic BPF is using BPF_MISC class to represent A = X and X = A moves. eBPF is using BPF_MOV | BPF_X | BPF_ALU code instead. Since there are no BPF_MISC operations in eBPF, the class 7 is used as BPF_ALU64 to mean exactly the same operations as BPF_ALU, but with 64-bit wide operands instead. So BPF_ADD | BPF_X | BPF_ALU64 means 64-bit addition, i.e.: dst_reg = dst_reg + src_regh]hX}Classic BPF is using BPF_MISC class to represent A = X and X = A moves. eBPF is using BPF_MOV | BPF_X | BPF_ALU code instead. Since there are no BPF_MISC operations in eBPF, the class 7 is used as BPF_ALU64 to mean exactly the same operations as BPF_ALU, but with 64-bit wide operands instead. So BPF_ADD | BPF_X | BPF_ALU64 means 64-bit addition, i.e.: dst_reg = dst_reg + src_reg}(hj?hhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMIhjhhubh)}(hXClassic BPF wastes the whole BPF_RET class to represent a single ``ret`` operation. Classic BPF_RET | BPF_K means copy imm32 into return register and perform function exit. eBPF is modeled to match CPU, so BPF_JMP | BPF_EXIT in eBPF means function exit only. The eBPF program needs to store return value into register R0 before doing a BPF_EXIT. Class 6 in eBPF is used as BPF_JMP32 to mean exactly the same operations as BPF_JMP, but with 32-bit wide operands for the comparisons instead.h](hAClassic BPF wastes the whole BPF_RET class to represent a single }(hjMhhhNhNubj)}(h``ret``h]hret}(hjUhhhNhNubah}(h]h ]h"]h$]h&]uh1jhjMubhX operation. Classic BPF_RET | BPF_K means copy imm32 into return register and perform function exit. eBPF is modeled to match CPU, so BPF_JMP | BPF_EXIT in eBPF means function exit only. The eBPF program needs to store return value into register R0 before doing a BPF_EXIT. Class 6 in eBPF is used as BPF_JMP32 to mean exactly the same operations as BPF_JMP, but with 32-bit wide operands for the comparisons instead.}(hjMhhhNhNubeh}(h]h ]h"]h$]h&]uh1hhhhMPhjhhubh)}(hFFor load and store instructions the 8-bit 'code' field is divided as::h]hIFor load and store instructions the 8-bit ‘code’ field is divided as:}(hjmhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMXhjhhubj )}(h+--------+--------+-------------------+ | 3 bits | 2 bits | 3 bits | | mode | size | instruction class | +--------+--------+-------------------+ (MSB) (LSB)h]h+--------+--------+-------------------+ | 3 bits | 2 bits | 3 bits | | mode | size | instruction class | +--------+--------+-------------------+ (MSB) (LSB)}hj{sbah}(h]h ]h"]h$]h&]jjuh1j hhhMZhjhhubh)}(hSize modifier is one of ...h]hSize modifier is one of ...}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhM`hjhhubj )}(hBPF_W 0x00 /* word */ BPF_H 0x08 /* half word */ BPF_B 0x10 /* byte */ BPF_DW 0x18 /* eBPF only, double word */h]hBPF_W 0x00 /* word */ BPF_H 0x08 /* half word */ BPF_B 0x10 /* byte */ BPF_DW 0x18 /* eBPF only, double word */}hjsbah}(h]h ]h"]h$]h&]jjuh1j hhhMdhjhhubh)}(h0... which encodes size of load/store operation::h]h/... which encodes size of load/store operation:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMihjhhubj )}(h;B - 1 byte H - 2 byte W - 4 byte DW - 8 byte (eBPF only)h]h;B - 1 byte H - 2 byte W - 4 byte DW - 8 byte (eBPF only)}hjsbah}(h]h ]h"]h$]h&]jjuh1j hhhMkhjhhubh)}(hMode modifier is one of::h]hMode modifier is one of:}(hjhhhNhNubah}(h]h ]h"]h$]h&]uh1hhhhMphjhhubj )}(hX+BPF_IMM 0x00 /* used for 32-bit mov in classic BPF and 64-bit in eBPF */ BPF_ABS 0x20 BPF_IND 0x40 BPF_MEM 0x60 BPF_LEN 0x80 /* classic BPF only, reserved in eBPF */ BPF_MSH 0xa0 /* classic BPF only, reserved in eBPF */ BPF_ATOMIC 0xc0 /* eBPF only, atomic operations */h]hX+BPF_IMM 0x00 /* used for 32-bit mov in classic BPF and 64-bit in eBPF */ BPF_ABS 0x20 BPF_IND 0x40 BPF_MEM 0x60 BPF_LEN 0x80 /* classic BPF only, reserved in eBPF */ BPF_MSH 0xa0 /* classic BPF only, reserved in eBPF */ BPF_ATOMIC 0xc0 /* eBPF only, atomic operations */}hjsbah}(h]h ]h"]h$]h&]jjuh1j hhhMrhjhhubeh}(h]opcode-encodingah ]h"]opcode encodingah$]h&]uh1hhhhhhhhKubeh}(h]classic-bpf-vs-ebpfah ]h"]classic bpf vs ebpfah$]h&]uh1hhhhhhhhKubeh}(h]h ]h"]h$]h&]sourcehuh1hcurrent_sourceN current_lineNsettingsdocutils.frontendValues)}(hN generatorN datestampN source_linkN source_urlN toc_backlinksjSfootnote_backlinksK sectnum_xformKstrip_commentsNstrip_elements_with_classesN strip_classesN report_levelK halt_levelKexit_status_levelKdebugNwarning_streamN tracebackinput_encoding utf-8-siginput_encoding_error_handlerstrictoutput_encodingutf-8output_encoding_error_handlerjerror_encodingutf-8error_encoding_error_handlerbackslashreplace language_codeenrecord_dependenciesNconfigN id_prefixhauto_id_prefixid dump_settingsNdump_internalsNdump_transformsNdump_pseudo_xmlNexpose_internalsNstrict_visitorN_disable_configN_sourcehʌ _destinationN _config_files]7/var/lib/git/docbuild/linux/Documentation/docutils.confafile_insertion_enabled raw_enabledKline_length_limitM'pep_referencesN pep_base_urlhttps://peps.python.org/pep_file_url_templatepep-%04drfc_referencesN rfc_base_url&https://datatracker.ietf.org/doc/html/ tab_widthKtrim_footnote_reference_spacesyntax_highlightlong smart_quotessmartquotes_locales]character_level_inline_markupdoctitle_xform docinfo_xformKsectsubtitle_xform image_loadinglinkembed_stylesheetcloak_email_addressessection_self_linkenvNubreporterNindirect_targets]substitution_defs}substitution_names}refnames}refids}nameids}(jjjju nametypes}(jjuh}(jhjju footnote_refs} citation_refs} autofootnotes]autofootnote_refs]symbol_footnotes]symbol_footnote_refs] footnotes] citations]autofootnote_startKsymbol_footnote_startK id_counter collectionsCounter}Rparse_messages]transform_messages] transformerN include_log] decorationNhhub.