On Mon, Feb 27, 2023 at 3:25 PM Yonghong Song <yhs@xxxxxxxx> wrote: > > > > 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. I don't quite understand how alias of the same insn with different encoding helps libbpf. One can argue that x86 has "aliases" for the same command. Like nop can be 2,3,4,5 and pretty much any number of bytes, but that's a different use case.
