All of lore.kernel.org
 help / color / mirror / Atom feed
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



             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.