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? Like 'relative or absolute' depends on arch. On x86-64 BPF_CALL is JITed into single x86 call instruction that has 32-bit immediate which is PC relative. Every JIT picks what's the best for that particular arch.
