From: Ralf Ramsauer <ralf@vmexit.de>
To: qemu-devel@nongnu.org,
Daniel Henrique Barboza <daniel.barboza@oss.qualcomm.com>
Cc: Ralf Ramsauer <ralf@vmexit.de>,
Ralf Ramsauer <ralf.ramsauer@oth-regensburg.de>,
qemu-riscv@nongnu.org, Palmer Dabbelt <palmer@dabbelt.com>,
Alistair Francis <alistair.francis@wdc.com>,
Weiwei Li <liwei1518@gmail.com>,
Liu Zhiwei <zhiwei_liu@linux.alibaba.com>,
Chao Liu <chao.liu@processmission.com>,
Bin Meng <bmeng.cn@gmail.com>,
Lukas Landgraf <lukas.landgraf@st.oth-regensburg.de>
Subject: [PATCH v3 0/4] hw/riscv: describe only the PLIC contexts that exist
Date: Thu, 22 Oct 2026 22:22:14 +0200 [thread overview]
Message-ID: <cover.1792700406.git.ralf@vmexit.de> (raw)
A PLIC context is addressed by its position in the 'interrupts-extended'
property, so the device tree and the device have to agree on which harts
contribute a context and in which order. On the virt machine they do
not: the device is built from riscv_plic_hart_config_string(), which
gives a hart a supervisor context only if it has supervisor mode, while
the device tree lists a machine and a supervisor context for every hart,
unconditionally. Boot with
-cpu rv64,h=false,s=false,u=false -smp 4
and the PLIC implements four contexts while the device tree advertises
eight. A guest that takes its context number from the property then gets
it wrong for every hart but the first. This is what an M-mode kernel on
virt runs into. sifive_u hardcodes the fu540 topology instead and has
the same latent problem, reachable with -cpu since the board restricts
neither the CPU type nor its extensions.
1 to 3 are the fix, 4 is cleanup and can be dropped, the rest does not
depend on it.
Tested by comparing the PLIC's 'interrupts-extended' against the
hart-config string of the PLIC device over 14 configurations of both
boards: 7 disagree before the series, all agree after, and the device
tree is unchanged wherever the default CPU is used. The KVM paths could
not be exercised, for lack of hardware.
v3:
- 4/4: the fdt helper takes has_m_mode from the board rather than
calling kvm_enabled() itself, keeping accelerator considerations in
the boards (Daniel)
v2:
- ask riscv_cpu_has_supervisor_mode() instead of reading RVS out of the
hart's CPURISCVState (Daniel)
- fold the KVM branch into the common loop, it describes the same rule
- fix sifive_u as well, and share the cell building between both boards
v1: https://lore.kernel.org/qemu-devel/20260927231838.236616-1-ralf@vmexit.de/
v2: https://lore.kernel.org/qemu-devel/20261021110838.3097959-1-ralf@vmexit.de/
Ralf Ramsauer (4):
target/riscv: add riscv_cpu_has_supervisor_mode()
hw/riscv/virt: only describe PLIC contexts that exist
hw/riscv/sifive_u: derive PLIC contexts from the harts
hw/riscv: share the PLIC interrupt cells between boards
hw/riscv/fdt-common.c | 18 ++++++++++++++++++
hw/riscv/sifive_u.c | 19 ++++++++-----------
hw/riscv/virt.c | 26 +++++++++-----------------
include/hw/riscv/fdt-common.h | 3 +++
target/riscv/cpu.c | 14 ++++++++++++++
target/riscv/cpu.h | 1 +
6 files changed, 53 insertions(+), 28 deletions(-)
base-commit: 4f4225874d4d3747ec1142e935dbd314218992fa
--
2.54.0
next reply other threads:[~2026-10-22 20:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-22 20:22 Ralf Ramsauer [this message]
2026-10-22 20:22 ` [PATCH v3 1/4] target/riscv: add riscv_cpu_has_supervisor_mode() Ralf Ramsauer
2026-10-23 2:19 ` Chao Liu
2026-10-22 20:22 ` [PATCH v3 2/4] hw/riscv/virt: only describe PLIC contexts that exist Ralf Ramsauer
2026-10-23 3:05 ` Chao Liu
2026-10-22 20:22 ` [PATCH v3 3/4] hw/riscv/sifive_u: derive PLIC contexts from the harts Ralf Ramsauer
2026-10-23 3:06 ` Chao Liu
2026-10-22 20:22 ` [PATCH v3 4/4] hw/riscv: share the PLIC interrupt cells between boards Ralf Ramsauer
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=cover.1792700406.git.ralf@vmexit.de \
--to=ralf@vmexit.de \
--cc=alistair.francis@wdc.com \
--cc=bmeng.cn@gmail.com \
--cc=chao.liu@processmission.com \
--cc=daniel.barboza@oss.qualcomm.com \
--cc=liwei1518@gmail.com \
--cc=lukas.landgraf@st.oth-regensburg.de \
--cc=palmer@dabbelt.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=ralf.ramsauer@oth-regensburg.de \
--cc=zhiwei_liu@linux.alibaba.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.