Re: [PATCH bpf-next 03/10] bpf: Support stack arguments for bpf functions

[Yonghong Song <yonghong.song@linux.dev>]

On 4/5/26 2:07 PM, Alexei Starovoitov wrote:
> On Thu, Apr 2, 2026 at 9:11 PM Yonghong Song <yonghong.song@linux.dev> wrote:
>>
>>
>> On 4/2/26 4:38 PM, Alexei Starovoitov wrote:
>>> On Wed, Apr 1, 2026 at 6:27 PM Yonghong Song <yonghong.song@linux.dev> wrote:
>>>> Currently BPF functions (subprogs) are limited to 5 register arguments.
>>>> With [1], the compiler can emit code that passes additional arguments
>>>> via a dedicated stack area through bpf register
>>>> BPF_REG_STACK_ARG_BASE (r12), introduced in the previous patch.
>>>>
>>>> The following is an example to show how stack arguments are saved
>>>> and transferred between caller and callee:
>>>>
>>>>     int foo(int a1, int a2, int a3, int a4, int a5, int a6, int a7) {
>>>>       ...
>>>>       bar(a1, a2, a3, a4, a5, a6, a7, a8);
>>>>       ...
>>>>     }
>>>>
>>>> The following is a illustration of stack allocation:
>>>>
>>>>      Caller (foo)                           Callee (bar)
>>>>      ============                           ============
>>>>      r12-relative stack arg area:           r12-relative stack arg area:
>>>>
>>>>      r12-8:  [incoming arg 6]          +--> r12-8:  [incoming arg 6] (from caller's outgoing r12-24)
>>>>      r12-16: [incoming arg 7]          |+-> r12-16: [incoming arg 7] (from caller's outgoing r12-32)
>>>>                                        ||+> r12-24: [incoming arg 8] (from caller's outgoing r12-40)
>>>>      ---- incoming/outgoing boundary   |||  ---- incoming/outgoing boundary
>>>>      r12-24: [outgoing arg 6 to callee]+||   ...
>>>>      r12-32: [outgoing arg 7 to callee]-+|
>>>>      r12-40: [outgoing arg 8 to callee]--+
>>> I haven't looked at the patch itself only at this diagram.
>>> How does it suppose to map to x86 calling convention?
>>> The shift is unusual.
>>> x86 is using fp-N for outgoing and fp+N for incoming.
>>> Why can't we use the same?
>>>
>> This is not for jit. The above transfer is for verification purpose.
>> For example, for callee, a load 'rX = *(u64 *)(r12 - 8)' can easily
>> get the value rX in callee since the value is copied from caller to callee.
> There shouldn't be any extra copy.
> For 7th and higher argument:
> the caller does 'stx [r12 - N]' and the callee does 'ldx [r12 + M]'
> and JIT emits them as-is only adjusting N and M constants.

Indeed, for 7th and higher arguments, ldx and stx and directly get
or store values in expected calling-convention places.

>
> For 6th argument JIT emits these two stx/ldx as moves to/from x86's r9.

For stx case, we should move the bottom stack value (6th argument)
to r9 and pop the bottom stack slot (8 bytes).

For ldx case, this is a bpf callee to access a bpf caller. In such
cases, r9 is not involved.