Lines Matching +full:1 +full:x64 +full:- +full:bit

18 Q: Is BPF a generic instruction set similar to x64 and arm64?
19 -------------------------------------------------------------
23 -------------------------------------
27 -----------------------------------------------------------
34 with two most used architectures x64 and arm64 (and takes into
45 A: NO. BPF calling convention only allows registers R1-R5 to be used
47 (unlike x64 ISA that allows msft, cdecl and other conventions)
50 -----------------------------------------------------------------
54 ------------------------------------------
62 Q: Does C-calling convention diminishes possible use cases?
63 -----------------------------------------------------------
75 ------------------------------------------------------------------------
79 bpf-to-bpf calls, indirect calls, loops, global variables,
80 jump tables, read-only sections, and all other normal constructs
84 ----------------------------------------
91 --------------------------------
96 program analysis. Currently, that limit is set to 1 million.
98 of 1 million NOP instructions. There is a limit to the maximum number
99 of subsequent branches, a limit to the number of nested bpf-to-bpf
103 There are also non-numerical limits that can cause the program
117 ---------------------------
129 Q: BPF instructions mapping not one-to-one to native CPU
131 Q: It seems not all BPF instructions are one-to-one to native CPU.
132 For example why BPF_JNE and other compare and jumps are not cpu-like?
137 Q: Why BPF_DIV instruction doesn't map to x64 div?
139 A: Because if we picked one-to-one relationship to x64 it would have made
141 needs div-by-zero runtime check.
160 New instructions that don't have one-to-one mapping to HW instructions
163 Q: BPF 32-bit subregister requirements
165 Q: BPF 32-bit subregisters have a requirement to zero upper 32-bits of BPF
166 registers which makes BPF inefficient virtual machine for 32-bit
167 CPU architectures and 32-bit HW accelerators. Can true 32-bit registers
172 But some optimizations on zero-ing the upper 32 bits for BPF registers are
174 programs for 32-bit architectures.
177 on 32-bit subregisters, provided the option -mattr=+alu32 is passed for
179 instructions for which zero-ing the upper bits of the destination register
180 is required, and insert an explicit zero-extension (zext) instruction
182 support, the JIT back-ends do not need to clear the upper bits for
184 back-ends simply need to support code generation for that mov32 variant,
188 Note that it is possible for a JIT back-end to have partial hardware
192 back-end: if one instruction has hardware support for zext and if the next
197 ------------------------------
211 ------------------------------------------
217 --------------------------------------------------------------
223 -------------------------------------------
229 ------------------------------
233 --------------------------------------------
237 -------------------------------------------
242 ---------------------------------------------
251 -------------------------------------------
252 A: Sort-of.
261 ----------------------------------------
269 by exporting kfuncs (which may return pointers to module-internal data
273 ----------------------------------------------
280 rejected by the verifier.  Also, for example, some of the bpf-callable
282 cc (congestion-control) implementations.  If any of these kernel
283 functions has changed, both the in-tree and out-of-tree kernel tcp cc
289 -----------------------------------------------------
296 them will need to change.  The BPF compile-once-run-everywhere (CO-RE)
301 -------------------------------------------------------------
308 -----------------------------------------------------------------------
341 ------------------------------------------------------------------------------