Re: [PATCH bpf-next 07/12] bpf, x86: Place kfunc arguments per the SysV calling convention

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

On 9/4/26 4:58 PM, Alexei Starovoitov wrote:
> On Thu Sep 3, 2026 at 10:10 PM PDT, Yonghong Song wrote:
>> The JIT hands each eightbyte the BPF calling convention passes an
>> argument in to the argument position of the same number, registers first,
>> so the two conventions agree unless the kernel one places an argument
>> somewhere else. Compute where SysV wants each eightbyte, and move the
>> ones that differ before the call.
>>
>> SysV disagrees over an argument that the registers left cannot hold: it
>> moves the whole of it to the stack and leaves the registers to the
>> arguments that follow, while the BPF convention splits it and keeps
>> filling slots in order. So for
>>
>>    u64 f(u64 a, u64 b, u64 c, u64 d, u64 e, struct pair s);
>>
>> the BPF convention puts s in the last argument register and the first
>> stack slot, while SysV puts it wholly on the stack. Add an argument after
>> s and it takes the register s vacated, which makes the moves a cycle, so
>> one value at a time waits in RAX, dead before a call.
>>
>> The outgoing argument area is sized for both conventions, as SysV can put
>> on the stack an argument the BPF slots kept in a register, and
>> bpf_jit_supports_kfunc_arg_slot() can now answer yes to any placement.
> What is SysV ? This change is about x86-64 ABI.

SysV refers to https://wiki.osdev.org/System_V_ABI#x86-64.

> How come BPF calling convention diverged from x86-64?

Let me explain the calling convention difference between BPF and x86_64.

For x86_64,
    rdi, rsi, rdx, rcx, r8, r9, <stack...>
So for
    foo(long a, __int128 b, __int128 c, __int128 d, __int128 e, long f)
the register/stack mapping:
    a:rdi, b:rsi/rdx, c:rcx/r8, d:stack, e:stack, f/r9

For bpf, the abi is simply sequential, e.g. for the above foo()
    a, b, c, d, e, f // no gap
For bpf, bar(long a, long b, __int128 c, __int128 d, __int128 e, long f, __int128 g)
    a, b, c, d, e, f, g // no gap

The upstream llvm:

SDValue BPFTargetLowering::LowerCall(TargetLowering::CallLoweringInfo &CLI,
                                      SmallVectorImpl<SDValue> &InVals) const {
...
   // Walk arg assignments
   for (size_t i = 0; i < OutVals.size(); ++i) {
     CCValAssign &VA = ArgLocs[i];
     SDValue &Arg = OutVals[i];

     // Promote the value if needed.
     switch (VA.getLocInfo()) {
     default:
       report_fatal_error("unhandled location info: " + Twine(VA.getLocInfo()));
     case CCValAssign::Full:
       break;
     case CCValAssign::SExt:
       Arg = DAG.getNode(ISD::SIGN_EXTEND, CLI.DL, VA.getLocVT(), Arg);
       break;
     case CCValAssign::ZExt:
       Arg = DAG.getNode(ISD::ZERO_EXTEND, CLI.DL, VA.getLocVT(), Arg);
       break;
     case CCValAssign::AExt:
       Arg = DAG.getNode(ISD::ANY_EXTEND, CLI.DL, VA.getLocVT(), Arg);
       break;
     }


     // Push arguments into RegsToPass vector
     if (VA.isRegLoc()) {
       RegsToPass.push_back(std::make_pair(VA.getLocReg(), Arg));
       continue;
     }

     if (VA.isMemLoc()) {
       int Off = -8 - VA.getLocMemOffset();
       if (Off < INT16_MIN) {
         fail(CLI.DL, DAG, "extra parameter stack depth exceeded limit");
         break;
       }

       // STORE_STACK_ARG requires i64 operands. With ALU32 mode, the CC
       // promotion may only extend to i32, so extend to i64 if needed.
       if (Arg.getValueType() != MVT::i64)
         Arg = DAG.getNode(ISD::ANY_EXTEND, CLI.DL, MVT::i64, Arg);

       SDValue OffVal = DAG.getConstant(Off, CLI.DL, MVT::i64);
       Chain = DAG.getNode(BPFISD::STORE_STACK_ARG, CLI.DL, MVT::Other, Chain,
                           OffVal, Arg);
       continue;
     }

     report_fatal_error("unhandled argument location");
   }

 From above, for a 16-byte struct e.g. __int128 or struct {long a; long b;};
they can have half in R5 and the other half in Stack. But this is not
allowed for x86_64.

arm64 has more constraints on top of x86_64. For any 16-byte (or > 8 byte)
argument, the argument must be 16-byte aligned (in registers or in stacks).
For the following example:
   foo(long a, __int128 b, __int128 c, __int128 d, __int128 e, long f, __int128 g)
the registers/stack:
   a: x0, b: x2/x3, c: x4/x5, d: x6/x7
   stack: e (offset 0), f (offset 16), g (offset 32).

> Maybe we should adjust bpf side instead.

We can keep llvm implementation but we can adjust bpf side in kernel.

For x86, if we have a reorder of an argument or a hole in the slots, reject.
For arm64, if there is a hole in the slots, reject.

This will simplify jit a lot.

WDYT?

> Looks like next patch is doing the same shift/move dance for arm64
> which is a sign that we got it wrong on bpf side.
> It needs to match x86/arm64.
>
> pw-bot: cr