Lines Matching +full:no +full:- +full:ref +full:- +full:current +full:- +full:limit

19 -------------------------------------------------------------
20 A: NO.
23 -------------------------------------
24 A: NO.
27 -----------------------------------------------------------
41 A: NO. BPF allows only register R0 to be used as return value.
45 A: NO. BPF calling convention only allows registers R1-R5 to be used
50 -----------------------------------------------------------------
51 A: NO.
54 ------------------------------------------
55 A: NO.
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 --------------------------------
92 A: The only limit known to the user space is BPF_MAXINSNS (4096).
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
100 calls, a limit to the number of the verifier states per instruction,
101 a limit to the number of maps used by the program.
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?
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
170 A: NO.
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 ------------------------------
208 lifecycle expectations as described in :ref:`BPF_kfunc_lifecycle_expectations`.
211 ------------------------------------------
212 A: NO. Tracepoints are tied to internal implementation details hence they are
217 --------------------------------------------------------------
218 A: NO. The places to which kprobes can attach are internal implementation
223 -------------------------------------------
229 ------------------------------
233 --------------------------------------------
234 A: NO. Classic BPF programs are converted into extend BPF instructions.
237 -------------------------------------------
238 A: NO. BPF programs can only call specific functions exposed as BPF helpers or
242 ---------------------------------------------
243 A: NO.
251 -------------------------------------------
252 A: Sort-of.
255 of the current task with bpf_probe_write_user(). Every time such
261 ----------------------------------------
269 by exporting kfuncs (which may return pointers to module-internal data
273 ----------------------------------------------
277 A: NO.
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
286 :ref:`BPF_kfunc_lifecycle_expectations` for details.
289 -----------------------------------------------------
293 A: NO.
296 them will need to change.  The BPF compile-once-run-everywhere (CO-RE)
301 -------------------------------------------------------------
302 A: NO.
308 -----------------------------------------------------------------------
316 NO, but see below.
337 In other words, no backwards compatibility is guaranteed if one using a type
341 ------------------------------------------------------------------------------
346 A: NO.
351 :ref:`BPF_kfunc_lifecycle_expectations` for details.