Re: [PATCH bpf-next v4 03/13] bpf: Wire up JIT support for 16-byte kfunc returns

[Eduard Zingerman <eddyz87@gmail.com>]

On Mon, 2026-08-10 at 17:09 -0700, Yonghong Song wrote:
> LLVM 23 returns an __int128, or a struct/union larger than 8 bytes and no
> larger than 16 bytes, in the BPF R0:R2 register pair. The previous patch
> taught the verifier about that convention; wire up the JIT side so that the
> second half of the return value actually lands in R2.
> 
> A kfunc returning more than 8 bytes hands the second half of the result
> back in RDX, the native x86-64 ABI's second return register. BPF R0 maps to
> RAX so it needs no move, but BPF R2 maps to RSI, so emit a RDX->RSI move
> after a BPF_PSEUDO_KFUNC_CALL whose function model reports ret_size > 8.
> 
> Placing the second return half into R2 is possible on any JIT, but it needs
> architecture-specific JIT work. Rather than requiring every JIT to
> implement it at once, add a bpf_jit_supports_kfunc_ret_reg_pair()
> capability, defaulting to false in the generic core; an architecture opts
> in once its JIT handles the R0:R2 pair, and the remaining ones are left for
> future work. The verifier enforces it in bpf_add_kfunc_call(), rejecting a
> kfunc whose return is larger than 8 bytes with -EOPNOTSUPP when the JIT
> lacks the capability. Only x86, arm64 and riscv are supported so far.
> 
> On arm64 and riscv the native second return register is already BPF R2 (x1
> in bpf2a64[] and a1 in regmap[] respectively), so the value is in the R0:R2
> register pair on return with no extra move, unlike x86 (RDX->RSI). This has
> been tested on x86 and arm64. The riscv path is expected to work by the
> same register-mapping reasoning as arm64 but has not been tested.
> 
> bpf_add_kfunc_call() also rejects a kfunc that is marked KF_FASTCALL and
> returns more than 8 bytes. The bpf_fastcall contract implemented by
> mark_fastcall_pattern_for_call() assumes a call clobbers R0 plus the
> registers holding its arguments, so a return in the R0:R2 pair would
> clobber an R2 the caller expects the fastcall pattern to preserve. Such
> a kfunc is rejected with -EOPNOTSUPP as well.
> 
> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
> ---

Acked-by: Eduard Zingerman <eddyz87@gmail.com>

...