Re: [PATCH RFC bpf-next 0/4] bpf: replace min/max fields with struct cnum{32,64}

[shenghao yuan <shenghaoyuan0928@163.com>]

Hi Alexei,

On 2026/4/23 0:13, Alexei Starovoitov wrote:
> On Wed, Apr 22, 2026 at 8:32 AM Yazhou Tang <tangyazhou@zju.edu.cn> wrote:
>>
>> Hi Alexei,
>>
>> Thanks for the quick response!
>>
>> On 4/22/26 11:03 PM, Alexei Starovoitov wrote:
>>> On Wed Apr 22, 2026 at 7:50 AM PDT, Yazhou Tang wrote:
>>>> This was built for potential integration into Solana BPF and is
>>>
>>> we were thinking about adding these insns as well
>>>
>>> uhmul64_imm   dst = ((u128)dst * (u128)imm)>>64       0x77    BPF_PQR BPF_UHMUL | BPF_K       v2
>>> uhmul64_reg   dst = ((u128)dst * (u128)src)>>64       0x7f    BPF_PQR BPF_UHMUL | BPF_X       v2
>>> shmul64_imm   dst = ((i128)dst * (i128)imm)>>64       0x87    BPF_PQR BPF_SHMUL | BPF_K       v2
>>> shmul64_reg   dst = ((i128)dst * (i128)src)>>64       0x8f    BPF_PQR BPF_SHMUL | BPF_X       v2
>>>
>>> if you have kernel patches for that please share.
>>
>> We haven't implemented the interpreter and JIT backends for these
>> new uhmul64 and shmul64 instructions yet. However, we are actually
>> very familiar with these specific high-half multiplication
>> instructions, as they are already implemented in Solana BPF
>> (which we work closely with).
>>
>> We would absolutely love to take this on for the Linux kernel.
>> We can prepare the implementation across several RFC patchsets,
>> which will include:
>>
>> 1. Verifier: The value analysis for these new uhmul/shmul instructions
>>      using tnum and the upcoming cnum, backed by our formal proofs.
>> 2. Interpreter: The core implementation in kernel/bpf/core.c for
>>      these 4 instructions.
>> 3. JIT support starting with x86_64 (and subsequently arm64, etc.).
>>
>> (Note: We assume the LLVM frontend/backend support for emitting
>> these instructions might be handled separately, but we are happy
>> to provide the kernel-side implementation first).
>>
>> For the initial RFC, we plan to focus on the first two parts
>> (the Interpreter and Verifier semantics) to establish the groundwork.
> 
> We need to see end-to-end first. Which means LLVM + x86 JIT.
> You can skip the interpreter completely.
> The verifier needs to check safety of the operations,
> but updates to cnum/tnum should be conservative. Just mark as unbounded.
> No need for formal proofs or cnum work.

Regarding new eBPF insns topic, we will give an end-to-end solution in the
next RFC proposal once a prototype is ready. Please let me know if there
are any additional points you would like to highlight, discuss, or share.

Alternatively, we can have a deeper discussion when the prototype is ready.

Best wishes,
Shenghao and Yazhou