diff mbox series

[bpf-next,v2] riscv, bpf: Add kfunc support for RV64

Message ID 20230220083203.2988238-1-pulehui@huaweicloud.com
State New
Headers
Series [bpf-next,v2] riscv, bpf: Add kfunc support for RV64 |

Commit Message

Pu Lehui Feb. 20, 2023, 8:32 a.m. UTC 
  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.

Suggested-by: Björn Töpel <bjorn@rivosinc.com>
Signed-off-by: Pu Lehui <pulehui@huawei.com>
---
v2:
- Fix email address mismatch.
 
 arch/riscv/net/bpf_jit_comp64.c | 5 +++++
 1 file changed, 5 insertions(+)

Comments

Björn Töpel Feb. 20, 2023, 2:34 p.m. UTC | #1 
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
Pu Lehui Feb. 21, 2023, 1:47 a.m. UTC | #2 
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
Björn Töpel Feb. 21, 2023, 7:02 a.m. UTC | #3 
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>
diff mbox series

Patch

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;
+}