On Fri, May 03, 2019 at 11:42:31AM +0100, Jiong Wang wrote: > This patch introduce new alu32 insn BPF_ZEXT, and allocate the unused > opcode 0xe0 to it. > > Compared with the other alu32 insns, zero extension on low 32-bit is the > only semantics for this instruction. It also allows various JIT back-ends > to do optimal zero extension code-gen. > > BPF_ZEXT is supposed to be encoded with BPF_ALU only, and is supposed to be > generated by the latter 32-bit optimization code inside verifier for those > arches that do not support hardware implicit zero extension only. > > It is not supposed to be used in user's program directly at the moment. > Therefore, no need to recognize it inside generic verification code. It > just need to be supported for execution on interpreter or related JIT > back-ends. uapi and the doc define it, but "it is not supposed to be used" ?! > Signed-off-by: Jiong Wang <jiong.wang@xxxxxxxxxxxxx> > --- > Documentation/networking/filter.txt | 10 ++++++++++ > include/uapi/linux/bpf.h | 3 +++ > kernel/bpf/core.c | 4 ++++ > tools/include/uapi/linux/bpf.h | 3 +++ > 4 files changed, 20 insertions(+) > > diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt > index 319e5e0..1cb3e42 100644 > --- a/Documentation/networking/filter.txt > +++ b/Documentation/networking/filter.txt > @@ -903,6 +903,16 @@ If BPF_CLASS(code) == BPF_ALU or BPF_ALU64 [ in eBPF ], BPF_OP(code) is one of: > 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 */ > + BPF_ZEXT 0xe0 /* eBPF BPF_ALU only: zero-extends low 32-bit */ > + > +Compared with BPF_ALU | BPF_MOV which zero-extends low 32-bit implicitly, > +BPF_ALU | BPF_ZEXT zero-extends low 32-bit explicitly. Such zero extension is wait. that's an excellent observation. alu|mov is exactly it. we do not need another insn. we probably can teach the verifier to recognize <<32, >>32 and replace with mov32
