From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F0377606A319 for ; Thu, 22 Oct 2026 20:22:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=vmexit.de header.i=@vmexit.de header.a=rsa-sha256 header.s=mail header.b=erNbhjJM Received: from localhost ([::1] helo=lists1p.gnu.org) by lists1p.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1xJzIz-0006wL-GK; Thu, 22 Oct 2026 16:22:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1xJzIx-0006vk-DB; Thu, 22 Oct 2026 16:22:27 -0400 Received: from vmexit.de ([159.195.53.62] helo=gizmo.vmexit.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1xJzIu-0006zK-QU; Thu, 22 Oct 2026 16:22:26 -0400 From: Ralf Ramsauer DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vmexit.de; s=mail; t=1792700541; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=vnU3Ac5PaVd363XOcE+D85c9O2nUssLl1R4mdO8nED8=; b=erNbhjJMm2oHnrsXZo9SZpNT/pm9vqQr99ODtxBDB4dnJ3seW9gkw7t0FRn9ph/i1xTpJN hLnY7xuLoMQR2W82RGStK2S19GN5JOyfo5WD3s2Ql+U0jM+YlyE5xdqPY5jkPop1c8uLyQ bWD76ZxI4Zp3jiZbMXfsXK3vBU+Hbqk= To: qemu-devel@nongnu.org, Daniel Henrique Barboza Cc: Ralf Ramsauer , Ralf Ramsauer , qemu-riscv@nongnu.org, Palmer Dabbelt , Alistair Francis , Weiwei Li , Liu Zhiwei , Chao Liu , Bin Meng , Lukas Landgraf Subject: [PATCH v3 0/4] hw/riscv: describe only the PLIC contexts that exist Date: Thu, 22 Oct 2026 22:22:14 +0200 Message-ID: X-Archived-By: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=159.195.53.62; envelope-from=ralf@vmexit.de; helo=gizmo.vmexit.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: qemu development List-Archive: List-Post: List-Help: List-Subscribe: , Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org X-Spam-Status: No, score=-10.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 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