From: Pu Lehui <[email protected]>
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 <[email protected]>
Signed-off-by: Pu Lehui <[email protected]>
---
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 <[email protected]> writes:
> From: Pu Lehui <[email protected]>
>
> 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 <[email protected]> writes:
>
>> From: Pu Lehui <[email protected]>
>>
>> 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/[email protected]/
> 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 <[email protected]> writes:
> On 2023/2/20 22:34, Björn Töpel wrote:
>> Pu Lehui <[email protected]> writes:
>>
>>> From: Pu Lehui <[email protected]>
>>>
>>> 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 <[email protected]>
On 2023/2/21 15:02, Björn Töpel wrote:
> Pu Lehui <[email protected]> writes:
>
>> On 2023/2/20 22:34, Björn Töpel wrote:
>>> Pu Lehui <[email protected]> writes:
>>>
>>>> From: Pu Lehui <[email protected]>
>>>>
>>>> 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 <[email protected]>
Thanks Bjorn, will rewrite commit message to make more sense, and send
new soon.