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

[Eduard Zingerman <eddyz87@gmail.com>]

On Wed, 2026-07-08 at 13:09 -0700, Yonghong Song wrote:
> Continue preparing <=16 byte aggregate return support by wiring up the JIT
> side of the R0:R2 return convention for kfuncs.
> 
> A kfunc returning more than 8 bytes (a small aggregate or an __int128)
> hands the second half of the result back in RDX, the native x86-64 ABI's
> second return register. BPF instead expects a 16-byte return in the
> R0:R2 register pair. 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.
> 
> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
> ---

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

[...]