SIMD-0173: SBPF instruction encoding improvements #173
Conversation
Lichtso
force-pushed
the
sbpf-instruction-encoding-improvements
branch
2 times, most recently
from
fd7428a to
326539d
Compare
Lichtso
force-pushed
the
sbpf-instruction-encoding-improvements
branch
from
326539d to
420bfec
Compare
Lichtso
force-pushed
the
sbpf-instruction-encoding-improvements
branch
from
ed85f62 to
06e14a6
Compare
| - `0x97`, `0x9C`, `0x9F` (`STDW`, `LDXDW`, `STXDW`) | ||
|
|
||
| When a `CALLX` instruction (opcode `0x8D`) is encountered during verification, | ||
| the `src` register field must be verified instead of the `imm` immediate field. |
There was a problem hiding this comment.
For information, (upstream) LLVM recently changed the encoding of CALLX to use dst register instead of the imm immediate field: llvm/llvm-project#81546 (this landed in LLVM 19.1.0).
Would modifying the proposal to use dst instead of src be acceptable?
There was a problem hiding this comment.
We could but it would require backports to v2.2.
Also, the "dst" field? The destination is for registers to be written to, which callx does not. They probably thought: Oh, the jump destination, that must be the destination field.
There was a problem hiding this comment.
We could but it would require backports to v2.2.
Thanks for the information. I was wondering whether SIMD-0173 was already frozen/not subject to change, as this Pull Request is not merged. It seems SBPF v2 (and v3 ?) are already frozen standards and a version bump would be needed to make other changes.
It feels like much effort for only few improvements, to change the register used by CALLX. I don't have the bandwidth (or motivation) to work on this. Feel free to mark this comment as resolved.
Also, the "dst" field? The destination is for registers to be written to, which callx does not. They probably thought: Oh, the jump destination, that must be the destination field.
I don't know the rationale behind the decision of choosing dst instead of src. Nevertheless, in the Linux kernel, the behavior of CALL (with an immediate ; opcode 0x85) changes depending on src:
src=0is used to encode calls to BPF helper kernel functions (immcontains the ID).src=BPF_PSEUDO_CALL=1is used to encode relative calls (immcontains a relative offset).src=BPF_PSEUDO_KFUNC_CALL=2is used to encode calls to kernel functions using their BTF identifiers.
While the Linux kernel does not support indirect calls (CALLX reg, opcode 0x8d) yet, I can imagine people working on eBPF not willing to re-use src to store the target address.
There was a problem hiding this comment.
For information (for future readers stumbling on this thread), modifying the encoding of callx to use the destination register (and to revert SIMD-0173) is now being discussed in SIMD-0377: eBPF ISA compatibility. The sBPF implementation was already modified: anza-xyz/sbpf#89
| - `0x27`, `0x2C`, `0x2F` (`STB`, `LDXB`, `STXB`) | ||
| - `0x37`, `0x3C`, `0x3F` (`STH`, `LDXH`, `STXH`) | ||
| - `0x87`, `0x8C`, `0x8F` (`STW`, `LDXW`, `STXW`) | ||
| - `0x97`, `0x9C`, `0x9F` (`STDW`, `LDXDW`, `STXDW`) |
There was a problem hiding this comment.
Probably a little late for my comment, but the critique is still valid. Repurposing instruction classes brings no immediate benefit for either the validator or developers. We can only reap potential positive effects of this change if coupled with a future SIMD. Having said that, modifications like this could be postponed to when the gains are clear and well documented.
6 participants
No description provided.