On Tue, Jun 22, 2021 at 12:31 AM Alex Ghiti <alex@xxxxxxxx> wrote: > > Hi Alexei, > > Le 22/06/2021 à 02:28, Alexei Starovoitov a écrit : > > On Sun, Jun 20, 2021 at 11:43 PM Alex Ghiti <alex@xxxxxxxx> wrote: > >> > >> Hi, > >> > >> Le 18/06/2021 à 19:32, Andrii Nakryiko a écrit : > >>> On Fri, Jun 18, 2021 at 2:13 AM Alex Ghiti <alex@xxxxxxxx> wrote: > >>>> > >>>> Hi guys, > >>>> > >>>> First, pardon my ignorance regarding BPF, the following might be silly. > >>>> > >>>> We were wondering here > >>>> https://patchwork.kernel.org/project/linux-riscv/patch/20210615004928.2d27d2ac@xhacker/ > >>>> if BPF programs that now have the capability to call kernel functions > >>>> (https://lwn.net/Articles/856005/) can also call modules function or > >>>> vice-versa? > >>> > >>> Not yet, but it was an explicit design consideration and there was > >>> public interest just recently. So I'd say this is going to happen > >>> sooner rather than later. > >>> > >>>> > >>>> The underlying important fact is that in riscv, we are limited to 2GB > >>>> offset to call functions and that restricts where we can place modules > >>>> and BPF regions wrt kernel (see Documentation/riscv/vm-layout.rst for > >>>> the current possibly wrong layout). > >>>> > >>>> So should we make sure that modules and BPF lie in the same 2GB region? > >>> > >>> Based on the above and what you are explaining about 2GB limits, I'd > >>> say yes?.. Or alternatively those 2GB restrictions might perhaps be > >>> lifted somehow? > >> > >> > >> Actually we have this limit when we have PC-relative branch which is our > >> current code model. To better understand what happened, I took a look at > >> our JIT implementation and noticed that BPF_CALL are implemented using > >> absolute addressing so for this pseudo-instruction, the limit I evoked > >> does not apply. How are the kernel (and modules) symbol addresses > >> resolved? Is it relative or absolute? Is there then any guarantee that a > >> kernel or module call will always emit a BPF_CALL? > > > > Are those questions for riscv bpf JIT experts? > > Yes more or less, sorry about that, I added Bjorn in cc in case he wants > to intervene. But I think my last question is relevant: Is there then > any guarantee that a kernel or module call will always emit a BPF_CALL? > Because that would mean that we don't need to place BPF close to modules > since BPF_CALL are JITed into an absolute branch in riscv. I don't understand what you mean with this question. BPF_CALL is a BPF instruction to call from bpf prog. Not into bpf prog. When kernel or module calls into JITed bpf prog they use indirect call insn of the given arch. In case of bpf dispatcher there is a generated asm code that uses jmp by register or retpoline style. So JITed bpf progs not only 'called' into. >From bpf prog the helpers and kernel funcs are called via BPF_CALL. And this bpf insn has 32-bit offset requirement across archs. So all callable functions have to be in the same 4G region. So far that was the case for all archs. If riscv is going to separate things by more than 4G it will cause plenty of headaches for riscv JIT.
