From: Pu Lehui <pulehui@huawei.com>
To: Kuan-Wei Chiu <visitorckw@gmail.com>, <ast@kernel.org>,
<daniel@iogearbox.net>, <andrii@kernel.org>, <eddyz87@gmail.com>,
<memxor@gmail.com>, <luke.r.nels@gmail.com>, <xi.wang@gmail.com>,
<pjw@kernel.org>, <palmer@dabbelt.com>, <aou@eecs.berkeley.edu>
Cc: <martin.lau@linux.dev>, <song@kernel.org>,
<yonghong.song@linux.dev>, <jolsa@kernel.org>,
<emil@etsalapatis.com>, <alex@ghiti.fr>, <jserv@ccns.ncku.edu.tw>,
<eleanor15x@gmail.com>, <marscheng@google.com>,
<bpf@vger.kernel.org>, <linux-riscv@lists.infradead.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH bpf-next v3 3/3] riscv, bpf: Add 32 bit atomic operations to RV32 JIT
Date: Tue, 7 Jul 2026 10:26:16 +0800 [thread overview]
Message-ID: <60384951-bde4-417f-babd-bfeabe003b1b@huawei.com> (raw)
In-Reply-To: <20260706172846.3876436-4-visitorckw@gmail.com>
On 2026/7/7 1:28, Kuan-Wei Chiu wrote:
> The RV32 BPF JIT compiler currently only supports the BPF_ADD atomic
> operation. Other 32 bit atomic operations (and, or, xor, xchg) and
> their BPF_FETCH variants are not supported and gracefully fall back to
> the interpreter.
>
> Since the RISC-V A extension is required for Linux on RV32, we can
> natively support these 32-bit BPF atomic operations by mapping them
> directly to the corresponding RISC-V amo*.w instructions.
>
> Implement BPF_ADD, BPF_AND, BPF_OR, BPF_XOR, and BPF_XCHG with and
> without BPF_FETCH. BPF_CMPXCHG requires a more complex lr.w/sc.w
> loop and is left to fall back to the interpreter.
>
> Before this patch:
> [ 138.862161] test_bpf: Summary: 1054 PASSED, 0 FAILED, [843/1042 JIT'ed]
>
> After this patch:
> [ 157.024124] test_bpf: Summary: 1054 PASSED, 0 FAILED, [902/1042 JIT'ed]
>
> Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
> ---
> arch/riscv/net/bpf_jit_comp32.c | 64 +++++++++++++++++++++++++++------
> 1 file changed, 53 insertions(+), 11 deletions(-)
>
> diff --git a/arch/riscv/net/bpf_jit_comp32.c b/arch/riscv/net/bpf_jit_comp32.c
> index 39e2b0b907dc..bf3fb971294c 100644
> --- a/arch/riscv/net/bpf_jit_comp32.c
> +++ b/arch/riscv/net/bpf_jit_comp32.c
> @@ -874,14 +874,58 @@ static int emit_load_r64(const s8 *dst, const s8 *src, s16 off,
> return 0;
> }
>
> -static int emit_store_r64(const s8 *dst, const s8 *src, s16 off,
> - struct rv_jit_context *ctx, const u8 size,
> - const u8 mode)
> +static int emit_bpf_atomic(const s8 *src, const s8 *rs,
pls add a dst param to pass in RV_REG_T0. It feels kinda hacky to just
use a temp register directly
> + struct rv_jit_context *ctx,
> + const struct bpf_insn *insn)
> +{
> + s32 imm = insn->imm;
> + bool is_fetch = (imm & BPF_FETCH) || (imm == BPF_XCHG);
> + s8 fetch_reg = is_fetch ? lo(rs) : RV_REG_ZERO;
> + int aq = is_fetch ? 1 : 0;
> + int rl = is_fetch ? 1 : 0;
> +
> + switch (imm) {
> + case BPF_ADD:
> + case BPF_ADD | BPF_FETCH:
> + emit(rv_amoadd_w(fetch_reg, lo(rs), RV_REG_T0, aq, rl), ctx);
> + break;
> + case BPF_AND:
> + case BPF_AND | BPF_FETCH:
> + emit(rv_amoand_w(fetch_reg, lo(rs), RV_REG_T0, aq, rl), ctx);
> + break;
> + case BPF_OR:
> + case BPF_OR | BPF_FETCH:
> + emit(rv_amoor_w(fetch_reg, lo(rs), RV_REG_T0, aq, rl), ctx);
> + break;
> + case BPF_XOR:
> + case BPF_XOR | BPF_FETCH:
> + emit(rv_amoxor_w(fetch_reg, lo(rs), RV_REG_T0, aq, rl), ctx);
> + break;
> + case BPF_XCHG:
> + emit(rv_amoswap_w(fetch_reg, lo(rs), RV_REG_T0, aq, rl), ctx);
> + break;
> + default:
> + return -1;
> + }
> +
> + if (is_fetch) {
> + emit(rv_addi(hi(rs), RV_REG_ZERO, 0), ctx);
> + bpf_put_reg64(src, rs, ctx);
> + }
> + return 0;
> +}
> +
> +static int emit_store_r64(const s8 *dst, const s8 *src,
> + struct rv_jit_context *ctx,
> + const struct bpf_insn *insn)
> {
> const s8 *tmp1 = bpf2rv32[TMP_REG_1];
> const s8 *tmp2 = bpf2rv32[TMP_REG_2];
> const s8 *rd = bpf_get_reg64(dst, tmp1, ctx);
> const s8 *rs = bpf_get_reg64(src, tmp2, ctx);
> + u8 size = BPF_SIZE(insn->code);
> + u8 mode = BPF_MODE(insn->code);
> + s16 off = insn->off;
>
> if (mode == BPF_ATOMIC && size != BPF_W)
> return -1;
> @@ -901,9 +945,9 @@ static int emit_store_r64(const s8 *dst, const s8 *src, s16 off,
> case BPF_MEM:
> emit(rv_sw(RV_REG_T0, 0, lo(rs)), ctx);
> break;
> - case BPF_ATOMIC: /* Only BPF_ADD supported */
> - emit(rv_amoadd_w(RV_REG_ZERO, lo(rs), RV_REG_T0, 0, 0),
> - ctx);
> + case BPF_ATOMIC:
> + if (emit_bpf_atomic(src, rs, ctx, insn))
> + return -1;
> break;
> }
> break;
> @@ -1303,21 +1347,19 @@ int bpf_jit_emit_insn(const struct bpf_insn *insn, struct rv_jit_context *ctx,
> src = tmp2;
> }
>
> - if (emit_store_r64(dst, src, off, ctx, BPF_SIZE(code),
> - BPF_MODE(code)))
> + if (emit_store_r64(dst, src, ctx, insn))
> return -1;
> break;
>
> case BPF_STX | BPF_ATOMIC | BPF_W:
> - if (insn->imm != BPF_ADD) {
> + if (insn->imm == BPF_CMPXCHG) {
> pr_info_once(
> "bpf-jit: not supported: atomic operation %02x ***\n",
> insn->imm);
> return -EFAULT;
> }
>
> - if (emit_store_r64(dst, src, off, ctx, BPF_SIZE(code),
> - BPF_MODE(code)))
> + if (emit_store_r64(dst, src, ctx, insn))
> return -1;
> break;
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
prev parent reply other threads:[~2026-07-07 2:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-06 17:28 [PATCH bpf-next v3 0/3] riscv, bpf: Add support for signed operations and 32-bit atomics Kuan-Wei Chiu
2026-07-06 17:28 ` [PATCH bpf-next v3 1/3] riscv, bpf: Add support for BPF_SDIV and BPF_SMOD in RV32 JIT Kuan-Wei Chiu
2026-07-06 18:12 ` bot+bpf-ci
2026-07-07 2:30 ` Pu Lehui
2026-07-07 2:21 ` Pu Lehui
2026-07-06 17:28 ` [PATCH bpf-next v3 2/3] riscv, bpf: Add support for BPF_MOVSX " Kuan-Wei Chiu
2026-07-06 17:28 ` [PATCH bpf-next v3 3/3] riscv, bpf: Add 32 bit atomic operations to " Kuan-Wei Chiu
2026-07-07 2:26 ` Pu Lehui [this message]
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=60384951-bde4-417f-babd-bfeabe003b1b@huawei.com \
--to=pulehui@huawei.com \
--cc=alex@ghiti.fr \
--cc=andrii@kernel.org \
--cc=aou@eecs.berkeley.edu \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=eleanor15x@gmail.com \
--cc=emil@etsalapatis.com \
--cc=jolsa@kernel.org \
--cc=jserv@ccns.ncku.edu.tw \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=luke.r.nels@gmail.com \
--cc=marscheng@google.com \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=song@kernel.org \
--cc=visitorckw@gmail.com \
--cc=xi.wang@gmail.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