On Fri, Mar 29, 2024 at 1:27 PM Andrii Nakryiko
<andrii.nakryiko@xxxxxxxxx> wrote:
>
> On Fri, Mar 29, 2024 at 11:47 AM Andrii Nakryiko <andrii@xxxxxxxxxx> wrote:
> >
> > If BPF JIT supports per-CPU LDX instructions, inline
> > bpf_get_smp_processor_id() to eliminate unnecessary function calls.
> >
> > Signed-off-by: Andrii Nakryiko <andrii@xxxxxxxxxx>
> > ---
> > kernel/bpf/verifier.c | 17 +++++++++++++++++
> > 1 file changed, 17 insertions(+)
> >
> > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > index edb650667f44..24caec8b200d 100644
> > --- a/kernel/bpf/verifier.c
> > +++ b/kernel/bpf/verifier.c
> > @@ -20072,6 +20072,23 @@ static int do_misc_fixups(struct bpf_verifier_env *env)
> > goto next_insn;
> > }
> >
> > + /* Implement bpf_get_smp_processor_id() inline. */
> > + if (insn->imm == BPF_FUNC_get_smp_processor_id &&
> > + prog->jit_requested && bpf_jit_supports_percpu_insns()) {
> > + insn_buf[0] = BPF_MOV32_IMM(BPF_REG_0, (u32)(long)&pcpu_hot.cpu_number);
>
> so CI reminds me that this part will have to be architecture-specific.
>
> We can keep BPF_FUNC_get_smp_processor_id inlining here in
> kernel/bpf/verifier.c, but have arch-specific #ifdef/#elif/#endif
> logic? Or we can have an arch_bpf_inline_helper() call or something,
> where different architectures can more cleanly implement arch-specific
> inlining logic? What would be the preferred way?
I'd gate it to CONFIG_X86_64 or have a weak function on arch side
that returns a patch as a set of bpf insns.
