1.. contents:: 2.. sectnum:: 3 4====================================== 5BPF Instruction Set Architecture (ISA) 6====================================== 7 8This document specifies the BPF instruction set architecture (ISA). 9 10Documentation conventions 11========================= 12 13For brevity and consistency, this document refers to families 14of types using a shorthand syntax and refers to several expository, 15mnemonic functions when describing the semantics of instructions. 16The range of valid values for those types and the semantics of those 17functions are defined in the following subsections. 18 19Types 20----- 21This document refers to integer types with the notation `SN` to specify 22a type's signedness (`S`) and bit width (`N`), respectively. 23 24.. table:: Meaning of signedness notation. 25 26 ==== ========= 27 S Meaning 28 ==== ========= 29 u unsigned 30 s signed 31 ==== ========= 32 33.. table:: Meaning of bit-width notation. 34 35 ===== ========= 36 N Bit width 37 ===== ========= 38 8 8 bits 39 16 16 bits 40 32 32 bits 41 64 64 bits 42 128 128 bits 43 ===== ========= 44 45For example, `u32` is a type whose valid values are all the 32-bit unsigned 46numbers and `s16` is a types whose valid values are all the 16-bit signed 47numbers. 48 49Functions 50--------- 51* htobe16: Takes an unsigned 16-bit number in host-endian format and 52 returns the equivalent number as an unsigned 16-bit number in big-endian 53 format. 54* htobe32: Takes an unsigned 32-bit number in host-endian format and 55 returns the equivalent number as an unsigned 32-bit number in big-endian 56 format. 57* htobe64: Takes an unsigned 64-bit number in host-endian format and 58 returns the equivalent number as an unsigned 64-bit number in big-endian 59 format. 60* htole16: Takes an unsigned 16-bit number in host-endian format and 61 returns the equivalent number as an unsigned 16-bit number in little-endian 62 format. 63* htole32: Takes an unsigned 32-bit number in host-endian format and 64 returns the equivalent number as an unsigned 32-bit number in little-endian 65 format. 66* htole64: Takes an unsigned 64-bit number in host-endian format and 67 returns the equivalent number as an unsigned 64-bit number in little-endian 68 format. 69* bswap16: Takes an unsigned 16-bit number in either big- or little-endian 70 format and returns the equivalent number with the same bit width but 71 opposite endianness. 72* bswap32: Takes an unsigned 32-bit number in either big- or little-endian 73 format and returns the equivalent number with the same bit width but 74 opposite endianness. 75* bswap64: Takes an unsigned 64-bit number in either big- or little-endian 76 format and returns the equivalent number with the same bit width but 77 opposite endianness. 78 79 80Definitions 81----------- 82 83.. glossary:: 84 85 Sign Extend 86 To `sign extend an` ``X`` `-bit number, A, to a` ``Y`` `-bit number, B ,` means to 87 88 #. Copy all ``X`` bits from `A` to the lower ``X`` bits of `B`. 89 #. Set the value of the remaining ``Y`` - ``X`` bits of `B` to the value of 90 the most-significant bit of `A`. 91 92.. admonition:: Example 93 94 Sign extend an 8-bit number ``A`` to a 16-bit number ``B`` on a big-endian platform: 95 :: 96 97 A: 10000110 98 B: 11111111 10000110 99 100Conformance groups 101------------------ 102 103An implementation does not need to support all instructions specified in this 104document (e.g., deprecated instructions). Instead, a number of conformance 105groups are specified. An implementation must support the base32 conformance 106group and may support additional conformance groups, where supporting a 107conformance group means it must support all instructions in that conformance 108group. 109 110The use of named conformance groups enables interoperability between a runtime 111that executes instructions, and tools as such compilers that generate 112instructions for the runtime. Thus, capability discovery in terms of 113conformance groups might be done manually by users or automatically by tools. 114 115Each conformance group has a short ASCII label (e.g., "base32") that 116corresponds to a set of instructions that are mandatory. That is, each 117instruction has one or more conformance groups of which it is a member. 118 119This document defines the following conformance groups: 120 121* base32: includes all instructions defined in this 122 specification unless otherwise noted. 123* base64: includes base32, plus instructions explicitly noted 124 as being in the base64 conformance group. 125* atomic32: includes 32-bit atomic operation instructions (see `Atomic operations`_). 126* atomic64: includes atomic32, plus 64-bit atomic operation instructions. 127* divmul32: includes 32-bit division, multiplication, and modulo instructions. 128* divmul64: includes divmul32, plus 64-bit division, multiplication, 129 and modulo instructions. 130* packet: deprecated packet access instructions. 131 132Instruction encoding 133==================== 134 135BPF has two instruction encodings: 136 137* the basic instruction encoding, which uses 64 bits to encode an instruction 138* the wide instruction encoding, which appends a second 64 bits 139 after the basic instruction for a total of 128 bits. 140 141Basic instruction encoding 142-------------------------- 143 144A basic instruction is encoded as follows:: 145 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | opcode | regs | offset | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | imm | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 152**opcode** 153 operation to perform, encoded as follows:: 154 155 +-+-+-+-+-+-+-+-+ 156 |specific |class| 157 +-+-+-+-+-+-+-+-+ 158 159 **specific** 160 The format of these bits varies by instruction class 161 162 **class** 163 The instruction class (see `Instruction classes`_) 164 165**regs** 166 The source and destination register numbers, encoded as follows 167 on a little-endian host:: 168 169 +-+-+-+-+-+-+-+-+ 170 |src_reg|dst_reg| 171 +-+-+-+-+-+-+-+-+ 172 173 and as follows on a big-endian host:: 174 175 +-+-+-+-+-+-+-+-+ 176 |dst_reg|src_reg| 177 +-+-+-+-+-+-+-+-+ 178 179 **src_reg** 180 the source register number (0-10), except where otherwise specified 181 (`64-bit immediate instructions`_ reuse this field for other purposes) 182 183 **dst_reg** 184 destination register number (0-10) 185 186**offset** 187 signed integer offset used with pointer arithmetic 188 189**imm** 190 signed integer immediate value 191 192Note that the contents of multi-byte fields ('offset' and 'imm') are 193stored using big-endian byte ordering on big-endian hosts and 194little-endian byte ordering on little-endian hosts. 195 196For example:: 197 198 opcode offset imm assembly 199 src_reg dst_reg 200 07 0 1 00 00 44 33 22 11 r1 += 0x11223344 // little 201 dst_reg src_reg 202 07 1 0 00 00 11 22 33 44 r1 += 0x11223344 // big 203 204Note that most instructions do not use all of the fields. 205Unused fields shall be cleared to zero. 206 207Wide instruction encoding 208-------------------------- 209 210Some instructions are defined to use the wide instruction encoding, 211which uses two 32-bit immediate values. The 64 bits following 212the basic instruction format contain a pseudo instruction 213with 'opcode', 'dst_reg', 'src_reg', and 'offset' all set to zero. 214 215This is depicted in the following figure:: 216 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | opcode | regs | offset | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | imm | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | reserved | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | next_imm | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 227**opcode** 228 operation to perform, encoded as explained above 229 230**regs** 231 The source and destination register numbers, encoded as explained above 232 233**offset** 234 signed integer offset used with pointer arithmetic 235 236**imm** 237 signed integer immediate value 238 239**reserved** 240 unused, set to zero 241 242**next_imm** 243 second signed integer immediate value 244 245Instruction classes 246------------------- 247 248The three least significant bits of the 'opcode' field store the instruction class: 249 250===== ===== =============================== =================================== 251class value description reference 252===== ===== =============================== =================================== 253LD 0x0 non-standard load operations `Load and store instructions`_ 254LDX 0x1 load into register operations `Load and store instructions`_ 255ST 0x2 store from immediate operations `Load and store instructions`_ 256STX 0x3 store from register operations `Load and store instructions`_ 257ALU 0x4 32-bit arithmetic operations `Arithmetic and jump instructions`_ 258JMP 0x5 64-bit jump operations `Arithmetic and jump instructions`_ 259JMP32 0x6 32-bit jump operations `Arithmetic and jump instructions`_ 260ALU64 0x7 64-bit arithmetic operations `Arithmetic and jump instructions`_ 261===== ===== =============================== =================================== 262 263Arithmetic and jump instructions 264================================ 265 266For arithmetic and jump instructions (``ALU``, ``ALU64``, ``JMP`` and 267``JMP32``), the 8-bit 'opcode' field is divided into three parts:: 268 269 +-+-+-+-+-+-+-+-+ 270 | code |s|class| 271 +-+-+-+-+-+-+-+-+ 272 273**code** 274 the operation code, whose meaning varies by instruction class 275 276**s (source)** 277 the source operand location, which unless otherwise specified is one of: 278 279 ====== ===== ============================================== 280 source value description 281 ====== ===== ============================================== 282 K 0 use 32-bit 'imm' value as source operand 283 X 1 use 'src_reg' register value as source operand 284 ====== ===== ============================================== 285 286**instruction class** 287 the instruction class (see `Instruction classes`_) 288 289Arithmetic instructions 290----------------------- 291 292``ALU`` uses 32-bit wide operands while ``ALU64`` uses 64-bit wide operands for 293otherwise identical operations. ``ALU64`` instructions belong to the 294base64 conformance group unless noted otherwise. 295The 'code' field encodes the operation as below, where 'src' and 'dst' refer 296to the values of the source and destination registers, respectively. 297 298===== ===== ======= ========================================================== 299name code offset description 300===== ===== ======= ========================================================== 301ADD 0x0 0 dst += src 302SUB 0x1 0 dst -= src 303MUL 0x2 0 dst \*= src 304DIV 0x3 0 dst = (src != 0) ? (dst / src) : 0 305SDIV 0x3 1 dst = (src != 0) ? (dst s/ src) : 0 306OR 0x4 0 dst \|= src 307AND 0x5 0 dst &= src 308LSH 0x6 0 dst <<= (src & mask) 309RSH 0x7 0 dst >>= (src & mask) 310NEG 0x8 0 dst = -dst 311MOD 0x9 0 dst = (src != 0) ? (dst % src) : dst 312SMOD 0x9 1 dst = (src != 0) ? (dst s% src) : dst 313XOR 0xa 0 dst ^= src 314MOV 0xb 0 dst = src 315MOVSX 0xb 8/16/32 dst = (s8,s16,s32)src 316ARSH 0xc 0 :term:`sign extending<Sign Extend>` dst >>= (src & mask) 317END 0xd 0 byte swap operations (see `Byte swap instructions`_ below) 318===== ===== ======= ========================================================== 319 320Underflow and overflow are allowed during arithmetic operations, meaning 321the 64-bit or 32-bit value will wrap. If BPF program execution would 322result in division by zero, the destination register is instead set to zero. 323If execution would result in modulo by zero, for ``ALU64`` the value of 324the destination register is unchanged whereas for ``ALU`` the upper 32532 bits of the destination register are zeroed. 326 327``{ADD, X, ALU}``, where 'code' = ``ADD``, 'source' = ``X``, and 'class' = ``ALU``, means:: 328 329 dst = (u32) ((u32) dst + (u32) src) 330 331where '(u32)' indicates that the upper 32 bits are zeroed. 332 333``{ADD, X, ALU64}`` means:: 334 335 dst = dst + src 336 337``{XOR, K, ALU}`` means:: 338 339 dst = (u32) dst ^ (u32) imm 340 341``{XOR, K, ALU64}`` means:: 342 343 dst = dst ^ imm 344 345Note that most instructions have instruction offset of 0. Only three instructions 346(``SDIV``, ``SMOD``, ``MOVSX``) have a non-zero offset. 347 348Division, multiplication, and modulo operations for ``ALU`` are part 349of the "divmul32" conformance group, and division, multiplication, and 350modulo operations for ``ALU64`` are part of the "divmul64" conformance 351group. 352The division and modulo operations support both unsigned and signed flavors. 353 354For unsigned operations (``DIV`` and ``MOD``), for ``ALU``, 355'imm' is interpreted as a 32-bit unsigned value. For ``ALU64``, 356'imm' is first :term:`sign extended<Sign Extend>` from 32 to 64 bits, and then 357interpreted as a 64-bit unsigned value. 358 359For signed operations (``SDIV`` and ``SMOD``), for ``ALU``, 360'imm' is interpreted as a 32-bit signed value. For ``ALU64``, 'imm' 361is first :term:`sign extended<Sign Extend>` from 32 to 64 bits, and then 362interpreted as a 64-bit signed value. 363 364Note that there are varying definitions of the signed modulo operation 365when the dividend or divisor are negative, where implementations often 366vary by language such that Python, Ruby, etc. differ from C, Go, Java, 367etc. This specification requires that signed modulo use truncated division 368(where -13 % 3 == -1) as implemented in C, Go, etc.: 369 370 a % n = a - n * trunc(a / n) 371 372The ``MOVSX`` instruction does a move operation with sign extension. 373``{MOVSX, X, ALU}`` :term:`sign extends<Sign Extend>` 8-bit and 16-bit operands into 32 374bit operands, and zeroes the remaining upper 32 bits. 375``{MOVSX, X, ALU64}`` :term:`sign extends<Sign Extend>` 8-bit, 16-bit, and 32-bit 376operands into 64 bit operands. Unlike other arithmetic instructions, 377``MOVSX`` is only defined for register source operands (``X``). 378 379The ``NEG`` instruction is only defined when the source bit is clear 380(``K``). 381 382Shift operations use a mask of 0x3F (63) for 64-bit operations and 0x1F (31) 383for 32-bit operations. 384 385Byte swap instructions 386---------------------- 387 388The byte swap instructions use instruction classes of ``ALU`` and ``ALU64`` 389and a 4-bit 'code' field of ``END``. 390 391The byte swap instructions operate on the destination register 392only and do not use a separate source register or immediate value. 393 394For ``ALU``, the 1-bit source operand field in the opcode is used to 395select what byte order the operation converts from or to. For 396``ALU64``, the 1-bit source operand field in the opcode is reserved 397and must be set to 0. 398 399===== ======== ===== ================================================= 400class source value description 401===== ======== ===== ================================================= 402ALU TO_LE 0 convert between host byte order and little endian 403ALU TO_BE 1 convert between host byte order and big endian 404ALU64 Reserved 0 do byte swap unconditionally 405===== ======== ===== ================================================= 406 407The 'imm' field encodes the width of the swap operations. The following widths 408are supported: 16, 32 and 64. Width 64 operations belong to the base64 409conformance group and other swap operations belong to the base32 410conformance group. 411 412Examples: 413 414``{END, TO_LE, ALU}`` with imm = 16/32/64 means:: 415 416 dst = htole16(dst) 417 dst = htole32(dst) 418 dst = htole64(dst) 419 420``{END, TO_BE, ALU}`` with imm = 16/32/64 means:: 421 422 dst = htobe16(dst) 423 dst = htobe32(dst) 424 dst = htobe64(dst) 425 426``{END, TO_LE, ALU64}`` with imm = 16/32/64 means:: 427 428 dst = bswap16(dst) 429 dst = bswap32(dst) 430 dst = bswap64(dst) 431 432Jump instructions 433----------------- 434 435``JMP32`` uses 32-bit wide operands and indicates the base32 436conformance group, while ``JMP`` uses 64-bit wide operands for 437otherwise identical operations, and indicates the base64 conformance 438group unless otherwise specified. 439The 'code' field encodes the operation as below: 440 441======== ===== ======= =============================== =================================================== 442code value src_reg description notes 443======== ===== ======= =============================== =================================================== 444JA 0x0 0x0 PC += offset {JA, K, JMP} only 445JA 0x0 0x0 PC += imm {JA, K, JMP32} only 446JEQ 0x1 any PC += offset if dst == src 447JGT 0x2 any PC += offset if dst > src unsigned 448JGE 0x3 any PC += offset if dst >= src unsigned 449JSET 0x4 any PC += offset if dst & src 450JNE 0x5 any PC += offset if dst != src 451JSGT 0x6 any PC += offset if dst > src signed 452JSGE 0x7 any PC += offset if dst >= src signed 453CALL 0x8 0x0 call helper function by address {CALL, K, JMP} only, see `Helper functions`_ 454CALL 0x8 0x1 call PC += imm {CALL, K, JMP} only, see `Program-local functions`_ 455CALL 0x8 0x2 call helper function by BTF ID {CALL, K, JMP} only, see `Helper functions`_ 456EXIT 0x9 0x0 return {CALL, K, JMP} only 457JLT 0xa any PC += offset if dst < src unsigned 458JLE 0xb any PC += offset if dst <= src unsigned 459JSLT 0xc any PC += offset if dst < src signed 460JSLE 0xd any PC += offset if dst <= src signed 461======== ===== ======= =============================== =================================================== 462 463The BPF program needs to store the return value into register R0 before doing an 464``EXIT``. 465 466Example: 467 468``{JSGE, X, JMP32}`` means:: 469 470 if (s32)dst s>= (s32)src goto +offset 471 472where 's>=' indicates a signed '>=' comparison. 473 474``{JA, K, JMP32}`` means:: 475 476 gotol +imm 477 478where 'imm' means the branch offset comes from insn 'imm' field. 479 480Note that there are two flavors of ``JA`` instructions. The 481``JMP`` class permits a 16-bit jump offset specified by the 'offset' 482field, whereas the ``JMP32`` class permits a 32-bit jump offset 483specified by the 'imm' field. A > 16-bit conditional jump may be 484converted to a < 16-bit conditional jump plus a 32-bit unconditional 485jump. 486 487All ``CALL`` and ``JA`` instructions belong to the 488base32 conformance group. 489 490Helper functions 491~~~~~~~~~~~~~~~~ 492 493Helper functions are a concept whereby BPF programs can call into a 494set of function calls exposed by the underlying platform. 495 496Historically, each helper function was identified by an address 497encoded in the imm field. The available helper functions may differ 498for each program type, but address values are unique across all program types. 499 500Platforms that support the BPF Type Format (BTF) support identifying 501a helper function by a BTF ID encoded in the imm field, where the BTF ID 502identifies the helper name and type. 503 504Program-local functions 505~~~~~~~~~~~~~~~~~~~~~~~ 506Program-local functions are functions exposed by the same BPF program as the 507caller, and are referenced by offset from the call instruction, similar to 508``JA``. The offset is encoded in the imm field of the call instruction. 509A ``EXIT`` within the program-local function will return to the caller. 510 511Load and store instructions 512=========================== 513 514For load and store instructions (``LD``, ``LDX``, ``ST``, and ``STX``), the 5158-bit 'opcode' field is divided as:: 516 517 +-+-+-+-+-+-+-+-+ 518 |mode |sz |class| 519 +-+-+-+-+-+-+-+-+ 520 521**mode** 522 The mode modifier is one of: 523 524 ============= ===== ==================================== ============= 525 mode modifier value description reference 526 ============= ===== ==================================== ============= 527 IMM 0 64-bit immediate instructions `64-bit immediate instructions`_ 528 ABS 1 legacy BPF packet access (absolute) `Legacy BPF Packet access instructions`_ 529 IND 2 legacy BPF packet access (indirect) `Legacy BPF Packet access instructions`_ 530 MEM 3 regular load and store operations `Regular load and store operations`_ 531 MEMSX 4 sign-extension load operations `Sign-extension load operations`_ 532 ATOMIC 6 atomic operations `Atomic operations`_ 533 ============= ===== ==================================== ============= 534 535**sz (size)** 536 The size modifier is one of: 537 538 ==== ===== ===================== 539 size value description 540 ==== ===== ===================== 541 W 0 word (4 bytes) 542 H 1 half word (2 bytes) 543 B 2 byte 544 DW 3 double word (8 bytes) 545 ==== ===== ===================== 546 547 Instructions using ``DW`` belong to the base64 conformance group. 548 549**class** 550 The instruction class (see `Instruction classes`_) 551 552Regular load and store operations 553--------------------------------- 554 555The ``MEM`` mode modifier is used to encode regular load and store 556instructions that transfer data between a register and memory. 557 558``{MEM, <size>, STX}`` means:: 559 560 *(size *) (dst + offset) = src 561 562``{MEM, <size>, ST}`` means:: 563 564 *(size *) (dst + offset) = imm 565 566``{MEM, <size>, LDX}`` means:: 567 568 dst = *(unsigned size *) (src + offset) 569 570Where '<size>' is one of: ``B``, ``H``, ``W``, or ``DW``, and 571'unsigned size' is one of: u8, u16, u32, or u64. 572 573Sign-extension load operations 574------------------------------ 575 576The ``MEMSX`` mode modifier is used to encode :term:`sign-extension<Sign Extend>` load 577instructions that transfer data between a register and memory. 578 579``{MEMSX, <size>, LDX}`` means:: 580 581 dst = *(signed size *) (src + offset) 582 583Where size is one of: ``B``, ``H``, or ``W``, and 584'signed size' is one of: s8, s16, or s32. 585 586Atomic operations 587----------------- 588 589Atomic operations are operations that operate on memory and can not be 590interrupted or corrupted by other access to the same memory region 591by other BPF programs or means outside of this specification. 592 593All atomic operations supported by BPF are encoded as store operations 594that use the ``ATOMIC`` mode modifier as follows: 595 596* ``{ATOMIC, W, STX}`` for 32-bit operations, which are 597 part of the "atomic32" conformance group. 598* ``{ATOMIC, DW, STX}`` for 64-bit operations, which are 599 part of the "atomic64" conformance group. 600* 8-bit and 16-bit wide atomic operations are not supported. 601 602The 'imm' field is used to encode the actual atomic operation. 603Simple atomic operation use a subset of the values defined to encode 604arithmetic operations in the 'imm' field to encode the atomic operation: 605 606======== ===== =========== 607imm value description 608======== ===== =========== 609ADD 0x00 atomic add 610OR 0x40 atomic or 611AND 0x50 atomic and 612XOR 0xa0 atomic xor 613======== ===== =========== 614 615 616``{ATOMIC, W, STX}`` with 'imm' = ADD means:: 617 618 *(u32 *)(dst + offset) += src 619 620``{ATOMIC, DW, STX}`` with 'imm' = ADD means:: 621 622 *(u64 *)(dst + offset) += src 623 624In addition to the simple atomic operations, there also is a modifier and 625two complex atomic operations: 626 627=========== ================ =========================== 628imm value description 629=========== ================ =========================== 630FETCH 0x01 modifier: return old value 631XCHG 0xe0 | FETCH atomic exchange 632CMPXCHG 0xf0 | FETCH atomic compare and exchange 633=========== ================ =========================== 634 635The ``FETCH`` modifier is optional for simple atomic operations, and 636always set for the complex atomic operations. If the ``FETCH`` flag 637is set, then the operation also overwrites ``src`` with the value that 638was in memory before it was modified. 639 640The ``XCHG`` operation atomically exchanges ``src`` with the value 641addressed by ``dst + offset``. 642 643The ``CMPXCHG`` operation atomically compares the value addressed by 644``dst + offset`` with ``R0``. If they match, the value addressed by 645``dst + offset`` is replaced with ``src``. In either case, the 646value that was at ``dst + offset`` before the operation is zero-extended 647and loaded back to ``R0``. 648 64964-bit immediate instructions 650----------------------------- 651 652Instructions with the ``IMM`` 'mode' modifier use the wide instruction 653encoding defined in `Instruction encoding`_, and use the 'src_reg' field of the 654basic instruction to hold an opcode subtype. 655 656The following table defines a set of ``{IMM, DW, LD}`` instructions 657with opcode subtypes in the 'src_reg' field, using new terms such as "map" 658defined further below: 659 660======= ========================================= =========== ============== 661src_reg pseudocode imm type dst type 662======= ========================================= =========== ============== 6630x0 dst = (next_imm << 32) | imm integer integer 6640x1 dst = map_by_fd(imm) map fd map 6650x2 dst = map_val(map_by_fd(imm)) + next_imm map fd data pointer 6660x3 dst = var_addr(imm) variable id data pointer 6670x4 dst = code_addr(imm) integer code pointer 6680x5 dst = map_by_idx(imm) map index map 6690x6 dst = map_val(map_by_idx(imm)) + next_imm map index data pointer 670======= ========================================= =========== ============== 671 672where 673 674* map_by_fd(imm) means to convert a 32-bit file descriptor into an address of a map (see `Maps`_) 675* map_by_idx(imm) means to convert a 32-bit index into an address of a map 676* map_val(map) gets the address of the first value in a given map 677* var_addr(imm) gets the address of a platform variable (see `Platform Variables`_) with a given id 678* code_addr(imm) gets the address of the instruction at a specified relative offset in number of (64-bit) instructions 679* the 'imm type' can be used by disassemblers for display 680* the 'dst type' can be used for verification and JIT compilation purposes 681 682Maps 683~~~~ 684 685Maps are shared memory regions accessible by BPF programs on some platforms. 686A map can have various semantics as defined in a separate document, and may or 687may not have a single contiguous memory region, but the 'map_val(map)' is 688currently only defined for maps that do have a single contiguous memory region. 689 690Each map can have a file descriptor (fd) if supported by the platform, where 691'map_by_fd(imm)' means to get the map with the specified file descriptor. Each 692BPF program can also be defined to use a set of maps associated with the 693program at load time, and 'map_by_idx(imm)' means to get the map with the given 694index in the set associated with the BPF program containing the instruction. 695 696Platform Variables 697~~~~~~~~~~~~~~~~~~ 698 699Platform variables are memory regions, identified by integer ids, exposed by 700the runtime and accessible by BPF programs on some platforms. The 701'var_addr(imm)' operation means to get the address of the memory region 702identified by the given id. 703 704Legacy BPF Packet access instructions 705------------------------------------- 706 707BPF previously introduced special instructions for access to packet data that were 708carried over from classic BPF. These instructions used an instruction 709class of ``LD``, a size modifier of ``W``, ``H``, or ``B``, and a 710mode modifier of ``ABS`` or ``IND``. The 'dst_reg' and 'offset' fields were 711set to zero, and 'src_reg' was set to zero for ``ABS``. However, these 712instructions are deprecated and should no longer be used. All legacy packet 713access instructions belong to the "packet" conformance group. 714