From: Bo Gan <ganboing@gmail.com>
To: Lukas Gerlach <lukas.gerlach@cispa.de>,
bpf@vger.kernel.org, linux-riscv@lists.infradead.org,
tech-speculation-barriers@lists.riscv.org
Cc: bjorn@kernel.org, ast@kernel.org, daniel@iogearbox.net,
luke.r.nels@gmail.com, xi.wang@gmail.com, palmer@dabbelt.com,
luis.gerhorst@fau.de, daniel.weber@cispa.de,
marton.bognar@kuleuven.be, jo.vanbulck@kuleuven.be,
michael.schwarz@cispa.de
Subject: Re: [PATCH] riscv, bpf: Emit fence.i for BPF_NOSPEC
Date: Mon, 12 Jan 2026 10:33:00 -0800 [thread overview]
Message-ID: <b39e9af7-bdbf-4e02-ab7e-ec24626cada4@gmail.com> (raw)
In-Reply-To: <20251228173753.56767-1-lukas.gerlach@cispa.de>
Hi Lukas,
Please also check out Ved's response from the Speculation Barrier TG:
https://lists.riscv.org/g/tech-speculation-barriers/message/21
I think the best way forward is to wait for the TG to clearly define
speculation barrier instructions, and use them for future cores. For
existing HW, emit a warning and do nothing. I don't want to see bpf
doing fence.i universally for all riscv. Neither do I like it guessing
this and that specific core implementation needing fence.i or not. We
simply don't know how each vendor design their cores. Let the vendor
tell us what's the best instruction to use for our existing HW. E.g.,
for JH7110, it's really U74 from Sifive, so we can ask them to fill-in
If we absolutely want fence.i as a best-effort kind of approach, then
I strongly suggest we make it opt-in. I'd imagine it'd be a very loud
noise if folks found the bpf perf on riscv suddenly regressed.
Bo
next prev parent reply other threads:[~2026-01-12 18:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-28 17:37 [PATCH] riscv, bpf: Emit fence.i for BPF_NOSPEC Lukas Gerlach
2026-01-05 23:28 ` Paul Walmsley
2026-01-06 8:44 ` [PATCH] riscv, bpf: add a speculation barrier " Lukas Gerlach
2026-01-07 8:26 ` Luis Gerhorst
2026-01-07 9:54 ` [PATCH] riscv, bpf: Emit fence.i " Lukas Gerlach
2026-01-07 17:52 ` Luis Gerhorst
2026-01-07 23:30 ` Samuel Holland
2026-01-08 10:05 ` Luis Gerhorst
2026-01-09 3:41 ` Bo Gan
2026-01-09 5:36 ` [tech-speculation-barriers] " Stefan O'Rear
2026-01-12 16:19 ` Luis Gerhorst
2026-01-12 18:33 ` Bo Gan [this message]
2026-01-13 1:51 ` Paul Walmsley
2026-01-15 13:13 ` Lukas Gerlach
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=b39e9af7-bdbf-4e02-ab7e-ec24626cada4@gmail.com \
--to=ganboing@gmail.com \
--cc=ast@kernel.org \
--cc=bjorn@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel.weber@cispa.de \
--cc=daniel@iogearbox.net \
--cc=jo.vanbulck@kuleuven.be \
--cc=linux-riscv@lists.infradead.org \
--cc=luis.gerhorst@fau.de \
--cc=lukas.gerlach@cispa.de \
--cc=luke.r.nels@gmail.com \
--cc=marton.bognar@kuleuven.be \
--cc=michael.schwarz@cispa.de \
--cc=palmer@dabbelt.com \
--cc=tech-speculation-barriers@lists.riscv.org \
--cc=xi.wang@gmail.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