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

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

On 9/7/26 9:33 PM, Alexei Starovoitov wrote:
> On Sun, Sep 6, 2026 at 1:15 PM Yonghong Song <yonghong.song@linux.dev> wrote:
>>
>>
>> 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.
> Why cannot we adjust bpf calling convention to match arm64/x86 the best?
> Since arm64 is stricter, I'd pick that style.
> There are no kfuncs that use int128 or 16+ byte args,
> so it's a matter of bpf subprogs calling bpf subprogs.
> Seems cleaner to adjust what llvm emits instead of forcing all jits to adapt.

The following is what I was suggested:

llvm: no change,

x86_64 jit:

+bool bpf_jit_supports_kfunc_arg_slot(u32 slots_used, u32 nslots, u32 align)
+{
+       if (slots_used >= 6)
+               return IS_ALIGNED((slots_used - 6) * sizeof(u64), align);
+
+       return slots_used + nslots <= 6;
+}

arm64 jit:

+bool bpf_jit_supports_kfunc_arg_slot(u32 slots_used, u32 nslots, u32 align)
+{
+       if (slots_used >= 8)
+               return IS_ALIGNED((slots_used - 8) * sizeof(u64), align);
+
+       if (!IS_ALIGNED(slots_used * sizeof(u64), align))
+               return false;
+
+       return slots_used + nslots <= 8;
+}

The above x86_64 and arm64 will reject for certain cases as in the above.

The alternative solution is to change llvm's. Let us say we want to have
arm64 calling convention. We may have

    slot 0: int
    slot 1: empty
    slot 2: first64 in int128
    slot 3: second64 in int128
    slot 4: int
    slot 5: empty
    slot 6: first64 in int128
    slot 7: second64 int int128
    slot 8: int

in llvm and it matches to arm64
but it has some issues in kernel as some slot is empty. (slot 1, slot 5).
and it needs calling convention change for x86_64.

So in llvm, we should have strict arm64 calling convention without holes.
That means the above slot 0->8 example will be rejected in llvm.
Is this what you suggested?