On 2/27/23 2:24 PM, Andrii Nakryiko wrote:
On Sun, Feb 26, 2023 at 10:31 AM Yonghong Song <yhs@xxxxxxxx> wrote:
Over the past, there are some discussions to extend bpf
instruction ISA to accommodate some new use cases or
fix some potential issues. These new instructions will
be included in new cpu flavor -mcpu=v4.
The following are the proposal to add new instructions in 6
different categories. The proposal is a little bit rough.
You can find bpf insn background information in
Documentation/bpf/instruction-set.rst. Compared to previous
proposal (v1) in
https://lore.kernel.org/bpf/01515302-c37d-2ee5-c950-2f556a4caad0@xxxxxxxx/
there are two changes:
. for sign extend load, removing alu32_mode differentiator
since alu32_mode is only a compiler asm syntax mechanism in
this case, and not involved in insn encoding.
. for sign extend mov, there is no support for sign extend
moving an imm to a register.
The corresponding llvm implementation is at
https://reviews.llvm.org/D144829
The following is the proposal details.
SDIV/SMOD (signed div and mod)
==============================
bpf already has unsigned DIV and MOD. They are encoded as
insn code(4 bits) source(1 bit) instruction class(3 bit) off(16 bits)
DIV 0x3 0/1 BPF_ALU/BPF_ALU64 0
MOD 0x9 0/1 BPF_ALU/BPF_ALU64 0
The current 'code' field only has two value left, 0xe and 0xf.
gcc used these two values (0xe and 0xf) for SDIV and SMOD.
But using these two values takes up all 'code' space and makes
future extension hard.
Here, I propose to encode SDIV/SMOD like below:
insn code(4 bits) source(1 bit) instruction class(3 bit) off(16 bits)
DIV 0x3 0/1 BPF_ALU/BPF_ALU64 1
MOD 0x9 0/1 BPF_ALU/BPF_ALU64 1
Basically, we reuse the same 'code' value but changing 'off' from 0 to 1
to indicate signed div/mod.
Sign extend load
================
Currently llvm generated normal load instructions are encoded like below.
mode(3 bits) size(2 bits) instruction class(3 bits)
BPF_MEM (0x3) 8/16/32/64 BPF_LDX
For mode, existing used values are 0x0, 0x1, 0x2, 0x3, 0x6.
The proposal is to use mod value 0x4 to encode sign extend loads.
mode(3 bits) size(2 bits) instruction class(3 bits)
BPF_SMEM (0x4) 8/16/32 BPF_LDX
can we define BPF_SMEM for 64-bit for completeness here? I can see
some situations where, for example, libbpf needs to switch between
BPF_MEM/BPF_SMEM based on CO-RE relocation and target type, and not
having to special-case 64-bit case would be nice.
It's minor, but so seems to be to support sign-extended 64-bit load
(which would be equivalent to non-sign-extended, of course).
We can support sign-extended 64-bit load. But compiler won't be
able to generate this insn since 64-bit load will be generated
with existing non-sign-extended load.
If this can make libbpf life easier, yes, we can do it.
Sign extend register mov
========================
Current BPF_MOV insn is encoded as
insn code(4 bits) source(1 bit) instruction class(3 bit) off(16 bits)
MOV 0xb 0/1 BPF_ALU/BPF_ALU64 0
Let us support sign extended move insn as defined below:
insn code(4 bits) source(1 bit) instruction class(3 bit) off(16 bits)
MOVS 0xb 1 BPF_ALU 8/16
MOVS 0xb 1 BPF_ALU64 8/16/32
will this be literal 8, 16, 32 decimal values or similarly to
BPF_{B,H,W,DW} we'll just have values 0, 1, 2, 3 to represent 8, 16,
32, 64?
Yes, 8/16/32 are decimal values similar to existing encoding of
be/le instruction.
Also, a similar question about uniformly supporting 32 for BPF_ALU and
64 for BPF_ALU64?
Similar to above 64bit SMEM, we could support 32bit sign extend for
BPF_ALU and 64bit sign extend for BPF_ALU64. Compiler won't pick
these insns during code generation, but libbpf and inline asm should
be free to use them.
In the above sign extended mov instruction, 'off' represents the 'size'.
For example, if BPF_ALU class, and 'off' is 8, which means sign
extend a 8-bit value (in register) to a 32-bit value. If BPF_ALU64 class,
the same 8-bit value will sign extend to a 64-bit value.
[...]
