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

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Tue Sep 8, 2026 at 11:43 AM PDT, Yonghong Song wrote:
>
>
> On 9/8/26 8:24 AM, Alexei Starovoitov wrote:
>> On Mon, Sep 7, 2026 at 10:02 PM Yonghong Song <yonghong.song@linux.dev> wrote:
>>>
>>> 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.
>> If such rejection applies to bpf2bpf calls then we cannot use this approach.
>> rust-bpf is using i128 here and there and we cannot change standard rust
>> crates to shift arguments to satisfy JITs.
>
> The above bpf_jit_supports_kfunc_arg_slot() is for jit, so this is not
> related to bpf2bpf calls. bpf2bpf calls work fine.
>
>>
>>> 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.
>> Are you saying that x86 won't have slot 1 and 5 empty?
>> and first i128 will be in slot 1 and 2.
>
> Yes. For x86, it looks like
>      slot 0: int
>      slot 1: first64 in int128
>      slot 2: second64 in int128
>      slot 3: int
>      slot 4: first64 in int128
>      slot 5: second64 int int128
>      slot 6: int
>
>> So if we go with arm64 convention the x86 jit would still need to shift.
>
> Yes.
>
>> If we go with x86 convention then arm64 jit would need to introduce holes?
>
> Yes.
>
>>
>> While current bpf convention forces both x86 and arm64 to shift slots?
>
> The current bpf convention assigned arguments in order without any gaps.
> So yes, it will force both x86 and arm64 to shift slots.
>
>>
>> I think it's better to align bpf with either x86 or arm64.
>
> I did some investigation. Looks like pretty hard.
> If we want to align bpf with x86 calling convention, we will need
> 6 register arguments, alignment requirement for stack (__int128)
> and register backfilling as the *common* calling convention.
> This will make arm64 harder.

I see. Because of 6th reg on x86 the JIT would still need to do the work.
Ok. let's keep bpf calling convention as-is then.

> I think we can do a better job by having common struct for the above info:
>     nr_arg_regs          // 6 for x86_64 and 8 for arm64
>     even_reg_align       // true for arm64
>     backfill_after_stack // true for x86_64
>     pad_stack_to_align   // true for both arm64 and x86_64
>     others if needed
>
> With such information, we can calculate position in verifier.c.
> So we have minimum change in JIT.

That makes sense to me.