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(+)

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

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.