* [PATCH bpf-next v2] riscv, bpf: Add kfunc support for RV64
@ 2023-02-20 8:32 Pu Lehui
2023-02-20 14:34 ` Björn Töpel
0 siblings, 1 reply; 5+ messages in thread
From: Pu Lehui @ 2023-02-20 8:32 UTC (permalink / raw)
To: bpf, linux-riscv, linux-kernel
Cc: Björn Töpel, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, Martin KaFai Lau, Song Liu, Yonghong Song,
John Fastabend, KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa,
Pu Lehui, Pu Lehui
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH bpf-next v2] riscv, bpf: Add kfunc support for RV64
2023-02-20 8:32 [PATCH bpf-next v2] riscv, bpf: Add kfunc support for RV64 Pu Lehui
@ 2023-02-20 14:34 ` Björn Töpel
2023-02-21 1:47 ` Pu Lehui
0 siblings, 1 reply; 5+ messages in thread
From: Björn Töpel @ 2023-02-20 14:34 UTC (permalink / raw)
To: Pu Lehui, bpf, linux-riscv, linux-kernel
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Pu Lehui,
Pu Lehui
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH bpf-next v2] riscv, bpf: Add kfunc support for RV64
2023-02-20 14:34 ` Björn Töpel
@ 2023-02-21 1:47 ` Pu Lehui
2023-02-21 7:02 ` Björn Töpel
0 siblings, 1 reply; 5+ messages in thread
From: Pu Lehui @ 2023-02-21 1:47 UTC (permalink / raw)
To: Björn Töpel, bpf, linux-riscv, linux-kernel
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Pu Lehui
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH bpf-next v2] riscv, bpf: Add kfunc support for RV64
2023-02-21 1:47 ` Pu Lehui
@ 2023-02-21 7:02 ` Björn Töpel
2023-02-21 13:39 ` Pu Lehui
0 siblings, 1 reply; 5+ messages in thread
From: Björn Töpel @ 2023-02-21 7:02 UTC (permalink / raw)
To: Pu Lehui, bpf, linux-riscv, linux-kernel
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa, Pu Lehui
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>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH bpf-next v2] riscv, bpf: Add kfunc support for RV64
2023-02-21 7:02 ` Björn Töpel
@ 2023-02-21 13:39 ` Pu Lehui
0 siblings, 0 replies; 5+ messages in thread
From: Pu Lehui @ 2023-02-21 13:39 UTC (permalink / raw)
To: Björn Töpel, Pu Lehui, bpf, linux-riscv, linux-kernel
Cc: Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Jiri Olsa
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-02-21 13:40 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-20 8:32 [PATCH bpf-next v2] riscv, bpf: Add kfunc support for RV64 Pu Lehui
2023-02-20 14:34 ` Björn Töpel
2023-02-21 1:47 ` Pu Lehui
2023-02-21 7:02 ` Björn Töpel
2023-02-21 13:39 ` Pu Lehui
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®