| Message ID | 20230220083203.2988238-1-pulehui@huaweicloud.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | BPF |
| Headers | show |
| Series | [bpf-next,v2] riscv, bpf: Add kfunc support for RV64 | expand |
Pu Lehui <pulehui@huaweicloud.com> writes: > From: Pu Lehui <pulehui@huawei.com> > > As another important missing piece of RV64 JIT, kfunc allow bpf programs > call kernel functions. For now, RV64 is sufficient to enable it. Thanks Lehui! Maybe we can reword/massage the commit message a bit? What do you think about something like: "Now that the BPF trampoline is supported by RISC-V, it is possible to use BPF programs with kfunc calls. Note that the trampoline functionality is only supported by RV64. Add bpf_jit_supports_kfunc_call() to the 64-bit JIT." Björn
On 2023/2/20 22:34, Björn Töpel wrote: > Pu Lehui <pulehui@huaweicloud.com> writes: > >> From: Pu Lehui <pulehui@huawei.com> >> >> As another important missing piece of RV64 JIT, kfunc allow bpf programs >> call kernel functions. For now, RV64 is sufficient to enable it. > > Thanks Lehui! > > Maybe we can reword/massage the commit message a bit? What do you think > about something like: > > "Now that the BPF trampoline is supported by RISC-V, it is possible to > use BPF programs with kfunc calls. > kfunc and bpf trampoline are functionally independent. kfunc [1], like bpf helper functions, allows bpf programs to call exported kernel functions, while bpf trampoline provides a more efficient way than kprobe to act as a mediator between kernel functions and bpf programs, and between bpf programs. In fact, it was already supported before the bpf trampoline implementation, I just turned it on. As for RV32 kfunc, it needs to do some registers parsing. [1] https://lore.kernel.org/bpf/20210325015124.1543397-1-kafai@fb.com/ > Note that the trampoline functionality is only supported by RV64. > > Add bpf_jit_supports_kfunc_call() to the 64-bit JIT." > > > Björn
Pu Lehui <pulehui@huaweicloud.com> writes: > On 2023/2/20 22:34, Björn Töpel wrote: >> Pu Lehui <pulehui@huaweicloud.com> writes: >> >>> From: Pu Lehui <pulehui@huawei.com> >>> >>> As another important missing piece of RV64 JIT, kfunc allow bpf programs >>> call kernel functions. For now, RV64 is sufficient to enable it. >> >> Thanks Lehui! >> >> Maybe we can reword/massage the commit message a bit? What do you think >> about something like: >> >> "Now that the BPF trampoline is supported by RISC-V, it is possible to >> use BPF programs with kfunc calls. >> > > kfunc and bpf trampoline are functionally independent. kfunc [1], like > bpf helper functions, allows bpf programs to call exported kernel > functions, while bpf trampoline provides a more efficient way than > kprobe to act as a mediator between kernel functions and bpf programs, > and between bpf programs. > > In fact, it was already supported before the bpf trampoline > implementation, I just turned it on. Good point. I guess my (incorrect) kfunc mental model was that struct_ops and kfunc were tightly coupled. (Then again, w/o struct_ops working kfunc is a bit half-working in my view.) Fair enough. I'm still a bit confused about the commit message, but happy with the patch. Acked-by: Björn Töpel <bjorn@rivosinc.com>
On 2023/2/21 15:02, Björn Töpel wrote: > Pu Lehui <pulehui@huaweicloud.com> writes: > >> On 2023/2/20 22:34, Björn Töpel wrote: >>> Pu Lehui <pulehui@huaweicloud.com> writes: >>> >>>> From: Pu Lehui <pulehui@huawei.com> >>>> >>>> As another important missing piece of RV64 JIT, kfunc allow bpf programs >>>> call kernel functions. For now, RV64 is sufficient to enable it. >>> >>> Thanks Lehui! >>> >>> Maybe we can reword/massage the commit message a bit? What do you think >>> about something like: >>> >>> "Now that the BPF trampoline is supported by RISC-V, it is possible to >>> use BPF programs with kfunc calls. >>> >> >> kfunc and bpf trampoline are functionally independent. kfunc [1], like >> bpf helper functions, allows bpf programs to call exported kernel >> functions, while bpf trampoline provides a more efficient way than >> kprobe to act as a mediator between kernel functions and bpf programs, >> and between bpf programs. >> >> In fact, it was already supported before the bpf trampoline >> implementation, I just turned it on. > > Good point. I guess my (incorrect) kfunc mental model was that > struct_ops and kfunc were tightly coupled. (Then again, w/o struct_ops > working kfunc is a bit half-working in my view.) > > Fair enough. I'm still a bit confused about the commit message, but > happy with the patch. > > Acked-by: Björn Töpel <bjorn@rivosinc.com> Thanks Bjorn, will rewrite commit message to make more sense, and send new soon.
diff --git a/arch/riscv/net/bpf_jit_comp64.c b/arch/riscv/net/bpf_jit_comp64.c index f5a668736c79..a9270366dc57 100644 --- a/arch/riscv/net/bpf_jit_comp64.c +++ b/arch/riscv/net/bpf_jit_comp64.c @@ -1751,3 +1751,8 @@ void bpf_jit_build_epilogue(struct rv_jit_context *ctx) { __build_epilogue(false, ctx); } + +bool bpf_jit_supports_kfunc_call(void) +{ + return true; +}