bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
To: Michael Ellerman <mpe@ellerman.id.au>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>,
	ykaliuta@redhat.com,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	song@kernel.org, johan.almbladh@anyfinetworks.com,
	Hari Bathini <hbathini@linux.ibm.com>, <bpf@vger.kernel.org>,
	<linuxppc-dev@lists.ozlabs.org>
Subject: [PATCH 13/13] powerpc64/bpf: Optimize instruction sequence used for function calls
Date: Thu,  6 Jan 2022 17:15:17 +0530	[thread overview]
Message-ID: <2a50d28963658be9703a49fb84a325e16adc264f.1641468127.git.naveen.n.rao@linux.vnet.ibm.com> (raw)
In-Reply-To: <cover.1641468127.git.naveen.n.rao@linux.vnet.ibm.com>

When calling BPF helpers, we load the function address to call into a
register. This can result in upto 5 instructions. Optimize this by
instead using the kernel toc in r2 and adjusting offset to the BPF
helper. This works since all BPF helpers are part of kernel text, and
all BPF programs/functions utilize the kernel TOC.

Further more:
- load the actual function entry address in elf v1, rather than loading
  it through the function descriptor address.
- load the Local Entry Point (LEP) in elf v2 skipping TOC setup.
- consolidate code across elf abi v1 and v2 by using r12 on both.
- skip the initial instruction setting up r2 in case of BPF function
  calls, since we already have the kernel TOC setup in r2.

Reported-by: Anton Blanchard <anton@ozlabs.org>
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
 arch/powerpc/net/bpf_jit_comp64.c | 30 +++++++++++++-----------------
 1 file changed, 13 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c
index 5da8e54d4d70b6..72179295f8e8c8 100644
--- a/arch/powerpc/net/bpf_jit_comp64.c
+++ b/arch/powerpc/net/bpf_jit_comp64.c
@@ -155,22 +155,20 @@ void bpf_jit_build_epilogue(u32 *image, struct codegen_context *ctx)
 static int bpf_jit_emit_func_call_hlp(u32 *image, struct codegen_context *ctx, u64 func)
 {
 	unsigned long func_addr = func ? ppc_function_entry((void *)func) : 0;
+	long reladdr;
 
 	if (WARN_ON_ONCE(!core_kernel_text(func_addr)))
 		return -EINVAL;
 
-#ifdef PPC64_ELF_ABI_v1
-	/* func points to the function descriptor */
-	PPC_LI64(b2p[TMP_REG_2], func);
-	/* Load actual entry point from function descriptor */
-	PPC_BPF_LL(b2p[TMP_REG_1], b2p[TMP_REG_2], 0);
-	/* ... and move it to CTR */
-	EMIT(PPC_RAW_MTCTR(b2p[TMP_REG_1]));
-#else
-	/* We can clobber r12 */
-	PPC_FUNC_ADDR(12, func);
-	EMIT(PPC_RAW_MTCTR(12));
-#endif
+	reladdr = func_addr - kernel_toc_addr();
+	if (reladdr > 0x7FFFFFFF || reladdr < -(0x80000000L)) {
+		pr_err("eBPF: address of %ps out of range of kernel_toc.\n", (void *)func);
+		return -ERANGE;
+	}
+
+	EMIT(PPC_RAW_ADDIS(_R12, _R2, PPC_HA(reladdr)));
+	EMIT(PPC_RAW_ADDI(_R12, _R12, PPC_LO(reladdr)));
+	EMIT(PPC_RAW_MTCTR(_R12));
 	EMIT(PPC_RAW_BCTRL());
 
 	return 0;
@@ -183,6 +181,9 @@ int bpf_jit_emit_func_call_rel(u32 *image, struct codegen_context *ctx, u64 func
 	if (WARN_ON_ONCE(func && is_module_text_address(func)))
 		return -EINVAL;
 
+	/* skip past descriptor (elf v1) and toc load (elf v2) */
+	func += FUNCTION_DESCR_SIZE + 4;
+
 	/* Load function address into r12 */
 	PPC_LI64(12, func);
 
@@ -199,11 +200,6 @@ int bpf_jit_emit_func_call_rel(u32 *image, struct codegen_context *ctx, u64 func
 	for (i = ctx->idx - ctx_idx; i < 5; i++)
 		EMIT(PPC_RAW_NOP());
 
-#ifdef PPC64_ELF_ABI_v1
-	/* Load actual entry point from function descriptor */
-	PPC_BPF_LL(12, 12, 0);
-#endif
-
 	EMIT(PPC_RAW_MTCTR(12));
 	EMIT(PPC_RAW_BCTRL());
 
-- 
2.34.1


  parent reply	other threads:[~2022-01-06 11:47 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-06 11:45 [PATCH 00/13] powerpc/bpf: Some fixes and updates Naveen N. Rao
2022-01-06 11:45 ` [PATCH 01/13] bpf: Guard against accessing NULL pt_regs in bpf_get_task_stack() Naveen N. Rao
2022-01-07 10:21   ` Daniel Borkmann
2022-01-10  8:57   ` Christophe Leroy
2022-01-10 10:36     ` Naveen N. Rao
2022-01-06 11:45 ` [PATCH 02/13] powerpc32/bpf: Fix codegen for bpf-to-bpf calls Naveen N. Rao
2022-01-10  9:06   ` Christophe Leroy
2022-01-10 10:52     ` Naveen N. Rao
2022-01-06 11:45 ` [PATCH 03/13] powerpc/bpf: Update ldimm64 instructions during extra pass Naveen N. Rao
2022-01-08 14:45   ` Jiri Olsa
2022-01-10  9:27   ` Christophe Leroy
2022-01-10 10:56     ` Naveen N. Rao
2022-01-06 11:45 ` [PATCH 04/13] tools/bpf: Rename 'struct event' to avoid naming conflict Naveen N. Rao
2022-01-07 10:21   ` Daniel Borkmann
2022-01-06 11:45 ` [PATCH 05/13] powerpc/bpf: Skip branch range validation during first pass Naveen N. Rao
2022-01-06 11:45 ` [PATCH 06/13] powerpc/bpf: Emit a single branch instruction for known short branch ranges Naveen N. Rao
2022-01-06 11:45 ` [PATCH 07/13] powerpc/bpf: Handle large branch ranges with BPF_EXIT Naveen N. Rao
2022-01-06 11:45 ` [PATCH 08/13] powerpc64/bpf: Limit 'ldbrx' to processors compliant with ISA v2.06 Naveen N. Rao
2022-01-06 11:45 ` [PATCH 09/13] powerpc64/bpf: Do not save/restore LR on each call to bpf_stf_barrier() Naveen N. Rao
2022-01-06 11:45 ` [PATCH 10/13] powerpc64/bpf: Use r12 for constant blinding Naveen N. Rao
2022-01-06 11:45 ` [PATCH 11/13] powerpc64/bpf elfv2: Setup kernel TOC in r2 on entry Naveen N. Rao
2022-01-10  9:20   ` Christophe Leroy
2022-01-11 10:31     ` Naveen N. Rao
2022-01-11 14:35       ` Christophe Leroy
2022-01-11 14:43         ` Christophe Leroy
2022-01-14 11:17           ` Naveen N. Rao
2022-01-06 11:45 ` [PATCH 12/13] powerpc64/bpf elfv1: Do not load TOC before calling functions Naveen N. Rao
2022-01-06 11:45 ` Naveen N. Rao [this message]
2022-01-06 21:46 ` [PATCH 00/13] powerpc/bpf: Some fixes and updates Daniel Borkmann
2022-01-07  7:36   ` Naveen N. Rao
2022-01-07 10:20     ` Daniel Borkmann
2022-01-10  3:47       ` Michael Ellerman
2022-01-16 10:41 ` Michael Ellerman

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=2a50d28963658be9703a49fb84a325e16adc264f.1641468127.git.naveen.n.rao@linux.vnet.ibm.com \
    --to=naveen.n.rao@linux.vnet.ibm.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=christophe.leroy@csgroup.eu \
    --cc=daniel@iogearbox.net \
    --cc=hbathini@linux.ibm.com \
    --cc=johan.almbladh@anyfinetworks.com \
    --cc=jolsa@redhat.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=song@kernel.org \
    --cc=ykaliuta@redhat.com \
    /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).