From: Hari Bathini <hbathini@linux.ibm.com>
To: adubey@linux.ibm.com, bpf@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: sachinpb@linux.ibm.com, venkat88@linux.ibm.com,
andrii@kernel.org, eddyz87@gmail.com, mykolal@fb.com,
ast@kernel.org, daniel@iogearbox.net, martin.lau@linux.dev,
song@kernel.org, yonghong.song@linux.dev,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
haoluo@google.com, jolsa@kernel.org, christophe.leroy@csgroup.eu,
naveen@kernel.org, maddy@linux.ibm.com, mpe@ellerman.id.au,
npiggin@gmail.com, memxor@gmail.com, iii@linux.ibm.com,
shuah@kernel.org
Subject: Re: [PATCH v2 6/6] powerpc64/bpf: Additional NVR handling for bpf_throw
Date: Sat, 17 Jan 2026 16:21:13 +0530 [thread overview]
Message-ID: <32757ffb-2fa8-448b-8c47-6979b430cad7@linux.ibm.com> (raw)
In-Reply-To: <20260114114450.30405-7-adubey@linux.ibm.com>
On 14/01/26 5:14 pm, adubey@linux.ibm.com wrote:
> From: Abhishek Dubey <adubey@linux.ibm.com>
>
> The bpf_throw() function never returns, if it has
> clobbered any callee-saved register, those will
> remain clobbered. The prologue must take care of
> saving all callee-saved registers in the frame of
> exception boundary program. Later these additional
> non volatile registers R14-R25 along with other
> NVRs are restored back in the epilogue of exception
> callback.
>
> To achieve above objective the frame size is
> determined dynamically to accommodate additional
> non volatile registers in exception boundary's frame.
> For non-exception boundary program, the frame size
> remains optimal. The additional instructions to
> save & restore r14-r25 registers are emitted only during
> exception boundary and exception callback respectively.
>
> Signed-off-by: Abhishek Dubey <adubey@linux.ibm.com>
> ---
> arch/powerpc/net/bpf_jit_comp64.c | 70 +++++++++++++++++++++++++++----
> 1 file changed, 63 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c
> index a6083dd9786c..941e0818c9ec 100644
> --- a/arch/powerpc/net/bpf_jit_comp64.c
> +++ b/arch/powerpc/net/bpf_jit_comp64.c
> @@ -32,21 +32,37 @@
> *
> * [ prev sp ] <-------------
> * [ tail_call_info ] 8 |
> - * [ nv gpr save area ] 6*8 |
> + * [ nv gpr save area ] 6*8 + (12*8) |
> * [ local_tmp_var ] 24 |
> * fp (r31) --> [ ebpf stack space ] upto 512 |
> * [ frame header ] 32/112 |
> * sp (r1) ---> [ stack pointer ] --------------
> + *
> + * Additional (12*8) in 'nv gpr save area' only in case of
> + * exception boundary.
> */
>
> /* for bpf JIT code internal usage */
> #define BPF_PPC_STACK_LOCALS 24
> +/*
> + * for additional non volatile registers(r14-r25) to be saved
> + * at exception boundary
> + */
> +#define BPF_PPC_EXC_STACK_SAVE (12*8)
> +
> /* stack frame excluding BPF stack, ensure this is quadword aligned */
> #define BPF_PPC_STACKFRAME (STACK_FRAME_MIN_SIZE + \
> BPF_PPC_STACK_LOCALS + \
> BPF_PPC_STACK_SAVE + \
> BPF_PPC_TAILCALL)
>
> +/*
> + * same as BPF_PPC_STACKFRAME with save area for additional
> + * non volatile registers saved at exception boundary.
> + * This is quad-word aligned.
> + */
> +#define BPF_PPC_EXC_STACKFRAME (BPF_PPC_STACKFRAME + BPF_PPC_EXC_STACK_SAVE)
> +
> /* BPF register usage */
> #define TMP_REG_1 (MAX_BPF_JIT_REG + 0)
> #define TMP_REG_2 (MAX_BPF_JIT_REG + 1)
> @@ -103,9 +119,12 @@ static inline bool bpf_has_stack_frame(struct codegen_context *ctx)
> * [ ... ] |
> * sp (r1) ---> [ stack pointer ] --------------
> * [ tail_call_info ] 8
> - * [ nv gpr save area ] 6*8
> + * [ nv gpr save area ] 6*8 + (12*8)
> * [ local_tmp_var ] 24
> * [ unused red zone ] 224
> + *
> + * Additional (12*8) in 'nv gpr save area' only in case of
> + * exception boundary.
> */
> static int bpf_jit_stack_local(struct codegen_context *ctx)
> {
> @@ -114,7 +133,11 @@ static int bpf_jit_stack_local(struct codegen_context *ctx)
> return STACK_FRAME_MIN_SIZE + ctx->stack_size;
> } else {
> /* Stack layout 2 */
> - return -(BPF_PPC_TAILCALL + BPF_PPC_STACK_SAVE + BPF_PPC_STACK_LOCALS);
> + return -(BPF_PPC_TAILCALL
> + + BPF_PPC_STACK_SAVE
> + + (ctx->exception_boundary || ctx->exception_cb ?
> + BPF_PPC_EXC_STACK_SAVE:0)
> + + BPF_PPC_STACK_LOCALS);
> }
> }
>
> @@ -125,9 +148,19 @@ int bpf_jit_stack_tailcallinfo_offset(struct codegen_context *ctx)
>
> static int bpf_jit_stack_offsetof(struct codegen_context *ctx, int reg)
> {
> - if (reg >= BPF_PPC_NVR_MIN && reg < 32)
> + int min_valid_nvreg = BPF_PPC_NVR_MIN;
> + /* Default frame size for all cases except exception boundary */
> + int frame_nvr_size = BPF_PPC_STACKFRAME;
> +
> + /* Consider all nv regs for handling exceptions */
> + if (ctx->exception_boundary || ctx->exception_cb) {
> + min_valid_nvreg = _R14;
> + frame_nvr_size = BPF_PPC_EXC_STACKFRAME;
> + }
> +
> + if (reg >= min_valid_nvreg && reg < 32)
> return (bpf_has_stack_frame(ctx) ?
> - (BPF_PPC_STACKFRAME + ctx->stack_size) : 0)
> + (frame_nvr_size + ctx->stack_size) : 0)
> - (8 * (32 - reg)) - BPF_PPC_TAILCALL;
>
> pr_err("BPF JIT is asking about unknown registers");
> @@ -189,7 +222,20 @@ void bpf_jit_build_prologue(u32 *image, struct codegen_context *ctx)
> EMIT(PPC_RAW_STD(_R0, _R1, PPC_LR_STKOFF));
> }
>
> - EMIT(PPC_RAW_STDU(_R1, _R1, -(BPF_PPC_STACKFRAME + ctx->stack_size)));
> + int stack_expand = ctx->exception_boundary || ctx->exception_cb ?
> + BPF_PPC_EXC_STACKFRAME : BPF_PPC_STACKFRAME;
> + EMIT(PPC_RAW_STDU(_R1, _R1, -(stack_expand + ctx->stack_size)));
[...]
> - EMIT(PPC_RAW_ADDI(_R1, _R1, BPF_PPC_STACKFRAME + ctx->stack_size));
> + int stack_shrink = ctx->exception_cb || ctx->exception_boundary ?
> + BPF_PPC_EXC_STACKFRAME : BPF_PPC_STACKFRAME;
> + EMIT(PPC_RAW_ADDI(_R1, _R1, stack_shrink + ctx->stack_size));
> +
An inline helper bpf_jit_stack_size() defined to return the stack
size in both prologue and epilogue while setting up and tearing
down the stack should be more elegant.
Also, IIUC, the JIT code to handle tailcall info is irrelevant for
all subprogs of a BPF program with seen_exception. JIT code in the
prologue for tailcall count handling can be skipped for exception_cb
at least?
- Hari
next prev parent reply other threads:[~2026-01-17 10:51 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-14 11:44 [PATCH v2 0/6] powerpc64/bpf: Support tailcalls with subprogs & BPF exceptions adubey
2026-01-14 11:44 ` [PATCH v2 1/6] powerpc64/bpf: Move tail_call_cnt to bottom of stack frame adubey
2026-01-14 12:25 ` bot+bpf-ci
2026-01-15 8:29 ` Christophe Leroy (CS GROUP)
2026-01-17 10:11 ` Hari Bathini
[not found] ` <3e1c5930518113f349625cfa80ce82f5@imap.linux.ibm.com>
2026-01-17 10:59 ` Hari Bathini
2026-01-14 11:44 ` [PATCH v2 2/6] powerpc64/bpf: Support tailcalls with subprogs adubey
2026-01-14 12:27 ` Christophe Leroy (CS GROUP)
[not found] ` <2d242f4476b61373da236d24272b0ec3@imap.linux.ibm.com>
2026-01-16 4:50 ` Hari Bathini
2026-01-16 7:49 ` Christophe Leroy (CS GROUP)
2026-01-16 13:59 ` Hari Bathini
2026-01-17 10:23 ` Hari Bathini
2026-01-14 11:44 ` [PATCH v2 3/6] powerpc64/bpf: Tailcall handling with trampolines adubey
2026-01-14 12:25 ` bot+bpf-ci
2026-01-14 19:39 ` kernel test robot
2026-01-17 10:39 ` Hari Bathini
2026-01-17 10:41 ` Hari Bathini
2026-01-14 11:44 ` [PATCH v2 4/6] powerpc64/bpf: Add arch_bpf_stack_walk() for BPF JIT adubey
2026-01-14 12:37 ` Christophe Leroy (CS GROUP)
[not found] ` <bec1dfbacced0198fa76bc59e73811c6@imap.linux.ibm.com>
2026-01-16 5:38 ` Hari Bathini
2026-01-14 11:44 ` [PATCH v2 5/6] powerpc64/bpf: Support exceptions adubey
2026-01-16 6:27 ` Hari Bathini
[not found] ` <77a6a07add66189fbc9b68a410911e3c@imap.linux.ibm.com>
[not found] ` <cf1aea1601d03d42b3afde367c29d26b@imap.linux.ibm.com>
2026-01-16 7:48 ` Hari Bathini
2026-01-14 11:44 ` [PATCH v2 6/6] powerpc64/bpf: Additional NVR handling for bpf_throw adubey
2026-01-14 12:35 ` bot+bpf-ci
2026-01-17 10:51 ` Hari Bathini [this message]
2026-01-14 12:28 ` [PATCH v2 0/6] powerpc64/bpf: Support tailcalls with subprogs & BPF exceptions Christophe Leroy (CS GROUP)
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=32757ffb-2fa8-448b-8c47-6979b430cad7@linux.ibm.com \
--to=hbathini@linux.ibm.com \
--cc=adubey@linux.ibm.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=iii@linux.ibm.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=mpe@ellerman.id.au \
--cc=mykolal@fb.com \
--cc=naveen@kernel.org \
--cc=npiggin@gmail.com \
--cc=sachinpb@linux.ibm.com \
--cc=sdf@fomichev.me \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=venkat88@linux.ibm.com \
--cc=yonghong.song@linux.dev \
/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