From: "Nicholas Piggin" <npiggin@gmail.com>
To: "Naveen N Rao" <naveen@kernel.org>,
<linuxppc-dev@lists.ozlabs.org>,
<linux-trace-kernel@vger.kernel.org>, <bpf@vger.kernel.org>
Cc: "Michael Ellerman" <mpe@ellerman.id.au>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Masami Hiramatsu" <mhiramat@kernel.org>,
"Christophe Leroy" <christophe.leroy@csgroup.eu>,
"Masahiro Yamada" <masahiroy@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>,
"Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"John Fastabend" <john.fastabend@gmail.com>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Song Liu" <song@kernel.org>, "Jiri Olsa" <jolsa@kernel.org>
Subject: Re: [RFC PATCH v3 11/11] powerpc64/bpf: Add support for bpf trampolines
Date: Mon, 01 Jul 2024 21:03:52 +1000 [thread overview]
Message-ID: <D2E5I4W6C23X.3A42AJCY8ODUJ@gmail.com> (raw)
In-Reply-To: <a88b5b57d7e9b6db96323a6d6b236d567ebd6443.1718908016.git.naveen@kernel.org>
On Fri Jun 21, 2024 at 5:09 AM AEST, Naveen N Rao wrote:
> Add support for bpf_arch_text_poke() and arch_prepare_bpf_trampoline()
> for 64-bit powerpc.
What do BPF trampolines give you?
> BPF prog JIT is extended to mimic 64-bit powerpc approach for ftrace
> having a single nop at function entry, followed by the function
> profiling sequence out-of-line and a separate long branch stub for calls
> to trampolines that are out of range. A dummy_tramp is provided to
> simplify synchronization similar to arm64.
Synrhonization - between BPF and ftrace interfaces?
> BPF Trampolines adhere to the existing ftrace ABI utilizing a
> two-instruction profiling sequence, as well as the newer ABI utilizing a
> three-instruction profiling sequence enabling return with a 'blr'. The
> trampoline code itself closely follows x86 implementation.
>
> While the code is generic, BPF trampolines are only enabled on 64-bit
> powerpc. 32-bit powerpc will need testing and some updates.
>
> Signed-off-by: Naveen N Rao <naveen@kernel.org>
Just a quick glance for now, and I don't know BPF code much.
> ---
> arch/powerpc/include/asm/ppc-opcode.h | 14 +
> arch/powerpc/net/bpf_jit.h | 11 +
> arch/powerpc/net/bpf_jit_comp.c | 702 +++++++++++++++++++++++++-
> arch/powerpc/net/bpf_jit_comp32.c | 7 +-
> arch/powerpc/net/bpf_jit_comp64.c | 7 +-
> 5 files changed, 738 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
> index 076ae60b4a55..9eaa2c5d9b73 100644
> --- a/arch/powerpc/include/asm/ppc-opcode.h
> +++ b/arch/powerpc/include/asm/ppc-opcode.h
> @@ -585,12 +585,26 @@
> #define PPC_RAW_MTSPR(spr, d) (0x7c0003a6 | ___PPC_RS(d) | __PPC_SPR(spr))
> #define PPC_RAW_EIEIO() (0x7c0006ac)
>
> +/* bcl 20,31,$+4 */
> +#define PPC_RAW_BCL() (0x429f0005)
This is the special bcl form that gives the current address.
Maybe call it PPC_RAW_BCL4()
>
> +void dummy_tramp(void);
> +
> +asm (
> +" .pushsection .text, \"ax\", @progbits ;"
> +" .global dummy_tramp ;"
> +" .type dummy_tramp, @function ;"
> +"dummy_tramp: ;"
> +#ifdef CONFIG_FTRACE_PFE_OUT_OF_LINE
> +" blr ;"
> +#else
> +" mflr 11 ;"
Can you just drop this instruction? The caller will always
have it in r11?
> +" mtctr 11 ;"
> +" mtlr 0 ;"
> +" bctr ;"
> +#endif
> +" .size dummy_tramp, .-dummy_tramp ;"
> +" .popsection ;"
> +);
> +
> +void bpf_jit_build_fentry_stubs(u32 *image, struct codegen_context *ctx)
> +{
> + int ool_stub_idx, long_branch_stub_idx;
> +
> + /*
> + * Out-of-line stub:
> + * mflr r0
> + * [b|bl] tramp
> + * mtlr r0 // only with CONFIG_FTRACE_PFE_OUT_OF_LINE
> + * b bpf_func + 4
> + */
> + ool_stub_idx = ctx->idx;
> + EMIT(PPC_RAW_MFLR(_R0));
> + EMIT(PPC_RAW_NOP());
> + if (IS_ENABLED(CONFIG_FTRACE_PFE_OUT_OF_LINE))
> + EMIT(PPC_RAW_MTLR(_R0));
> + WARN_ON_ONCE(!is_offset_in_branch_range(4 - (long)ctx->idx * 4)); /* TODO */
> + EMIT(PPC_RAW_BRANCH(4 - (long)ctx->idx * 4));
> +
> + /*
> + * Long branch stub:
> + * .long <dummy_tramp_addr>
> + * mflr r11
> + * bcl 20,31,$+4
> + * mflr r12
> + * ld r12, -8-SZL(r12)
> + * mtctr r12
> + * mtlr r11 // needed to retain ftrace ABI
> + * bctr
> + */
You could avoid clobbering LR on >= POWER9 with addpcis instruction. Or
use a pcrel load with pcrel even. I guess that's something to do later.
Thanks,
Nick
next prev parent reply other threads:[~2024-07-01 11:04 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-20 18:54 [RFC PATCH v3 00/11] powerpc: Add support for ftrace direct and BPF trampolines Naveen N Rao
2024-06-20 18:54 ` [RFC PATCH v3 01/11] powerpc/kprobes: Use ftrace to determine if a probe is at function entry Naveen N Rao
2024-07-01 8:40 ` Nicholas Piggin
2024-07-01 18:18 ` Naveen N Rao
2024-06-20 18:54 ` [RFC PATCH v3 02/11] powerpc/ftrace: Unify 32-bit and 64-bit ftrace entry code Naveen N Rao
2024-07-01 8:57 ` Nicholas Piggin
2024-07-01 18:34 ` Naveen N Rao
2024-06-20 18:54 ` [RFC PATCH v3 03/11] powerpc/module_64: Convert #ifdef to IS_ENABLED() Naveen N Rao
2024-07-01 9:01 ` Nicholas Piggin
2024-06-20 18:54 ` [RFC PATCH v3 04/11] powerpc/ftrace: Remove pointer to struct module from dyn_arch_ftrace Naveen N Rao
2024-07-01 9:27 ` Nicholas Piggin
2024-07-01 18:51 ` Naveen N Rao
2024-06-20 18:54 ` [RFC PATCH v3 05/11] kbuild: Add generic hook for architectures to use before the final vmlinux link Naveen N Rao
2024-07-01 9:30 ` Nicholas Piggin
2024-06-20 18:54 ` [RFC PATCH v3 06/11] powerpc64/ftrace: Move ftrace sequence out of line Naveen N Rao
2024-07-01 10:39 ` Nicholas Piggin
2024-07-01 19:44 ` Naveen N Rao
2024-06-20 18:54 ` [RFC PATCH v3 07/11] powerpc/ftrace: Add support for DYNAMIC_FTRACE_WITH_CALL_OPS Naveen N Rao
2024-06-20 18:54 ` [RFC PATCH v3 08/11] powerpc/ftrace: Add support for DYNAMIC_FTRACE_WITH_DIRECT_CALLS Naveen N Rao
2024-06-20 18:54 ` [RFC PATCH v3 09/11] samples/ftrace: Add support for ftrace direct samples on powerpc Naveen N Rao
2024-06-20 19:09 ` [RFC PATCH v3 10/11] powerpc64/bpf: Fold bpf_jit_emit_func_call_hlp() into bpf_jit_emit_func_call_rel() Naveen N Rao
2024-06-20 19:09 ` [RFC PATCH v3 11/11] powerpc64/bpf: Add support for bpf trampolines Naveen N Rao
2024-07-01 11:03 ` Nicholas Piggin [this message]
2024-07-01 19:58 ` Naveen N Rao
2024-06-24 11:59 ` [RFC PATCH v3 00/11] powerpc: Add support for ftrace direct and BPF trampolines Vishal Chourasia
2024-07-03 11:11 ` Vishal Chourasia
2024-07-14 7:52 ` Naveen N Rao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D2E5I4W6C23X.3A42AJCY8ODUJ@gmail.com \
--to=npiggin@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=daniel@iogearbox.net \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mark.rutland@arm.com \
--cc=masahiroy@kernel.org \
--cc=mhiramat@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=naveen@kernel.org \
--cc=rostedt@goodmis.org \
--cc=song@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).