aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux/filter.h
diff options
context:
space:
mode:
authorJiong Wang <jiong.wang@netronome.com>2019-05-24 23:25:15 +0100
committerAlexei Starovoitov <ast@kernel.org>2019-05-24 18:58:37 -0700
commita4b1d3c1ddf6cb441187b6c130a473c16a05a356 (patch)
treefa54a491f3095c32cad767328a643211f6990951 /include/linux/filter.h
parentbpf: introduce new mov32 variant for doing explicit zero extension (diff)
downloadlinux-dev-a4b1d3c1ddf6cb441187b6c130a473c16a05a356.tar.xz
linux-dev-a4b1d3c1ddf6cb441187b6c130a473c16a05a356.zip
bpf: verifier: insert zero extension according to analysis result
After previous patches, verifier will mark a insn if it really needs zero extension on dst_reg. It is then for back-ends to decide how to use such information to eliminate unnecessary zero extension code-gen during JIT compilation. One approach is verifier insert explicit zero extension for those insns that need zero extension in a generic way, JIT back-ends then do not generate zero extension for sub-register write at default. However, only those back-ends which do not have hardware zero extension want this optimization. Back-ends like x86_64 and AArch64 have hardware zero extension support that the insertion should be disabled. This patch introduces new target hook "bpf_jit_needs_zext" which returns false at default, meaning verifier zero extension insertion is disabled at default. A back-end could override this hook to return true if it doesn't have hardware support and want verifier insert zero extension explicitly. Offload targets do not use this native target hook, instead, they could get the optimization results using bpf_prog_offload_ops.finalize. NOTE: arches could have diversified features, it is possible for one arch to have hardware zero extension support for some sub-register write insns but not for all. For example, PowerPC, SPARC have zero extended loads, but not for alu32. So when verifier zero extension insertion enabled, these JIT back-ends need to peephole insns to remove those zero extension inserted for insn that actually has hardware zero extension support. The peephole could be as simple as looking the next insn, if it is a special zero extension insn then it is safe to eliminate it if the current insn has hardware zero extension support. Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by: Jiong Wang <jiong.wang@netronome.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Diffstat (limited to 'include/linux/filter.h')
-rw-r--r--include/linux/filter.h1
1 files changed, 1 insertions, 0 deletions
diff --git a/include/linux/filter.h b/include/linux/filter.h
index bb10ffb88452..ba8b65270e0d 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -825,6 +825,7 @@ u64 __bpf_call_base(u64 r1, u64 r2, u64 r3, u64 r4, u64 r5);
struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog);
void bpf_jit_compile(struct bpf_prog *prog);
+bool bpf_jit_needs_zext(void);
bool bpf_helper_changes_pkt_data(void *func);
static inline bool bpf_dump_raw_ok(void)