From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844126; cv=none; d=zohomail.com; s=zohoarc; b=hJ10qf7RT6d/bJ64B3m/xEc/JUQoz99iYP5laFxetvGcZNnwJZwS7p7FFD2ZI9QK3PYIdKoP5PUyz93HchxcoiTLtVGbGDNyHduzSXniWGsOV7BoblcQp8TZQD4+ph/xGwJhIC4Jw5Ci9RqXDhT7oGbnVuNrpog3sg1GVz0P0CQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844126; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=gfybd4V4UjgdMJm9L9K0Iew+0ete1Kw2IvE21GRtIMc=; b=OgTN8SfFchP4M8+pVcmz++ZVbOMBI6aEPGjSTr8B4TFwpK4DH+kcrvyCWNKD9P/GVcj/+HjnzcwQS4fyIAnBC4Gt82vG2a2KrjU6zBxwHuiDa4DOn9om8I1S0ezwBOB/Ov5tWlnMrqkQi0kdMyStARvgvBAX+6DOch3Gi/EP23w= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844126245952.8989180360161; Thu, 27 Aug 2026 08:22:06 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400920.1636548 (Exim 4.92) (envelope-from ) id 1wzbvD-0006Gk-Qg; Thu, 27 Aug 2026 15:21:43 +0000 Received: by outflank-mailman (output) from mailman id 1400920.1636548; Thu, 27 Aug 2026 15:21:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbvD-0006GU-N1; Thu, 27 Aug 2026 15:21:43 +0000 Received: by outflank-mailman (input) for mailman id 1400920; Thu, 27 Aug 2026 15:21:42 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvB-00062n-VX for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:21:41 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvB-00Fi7E-CP for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:21:41 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a905604-bab6-0a2a0a5309dd-0a2a4507d2f8-2 for ; Thu, 27 Aug 2026 17:21:41 +0200 Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a905605-b4ea-0a2a45070019-d1558035bd87-3 for ; Thu, 27 Aug 2026 17:21:41 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-49556f97a9dso6058325e9.1 for ; Thu, 27 Aug 2026 08:21:41 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.21.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:21:40 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844101; x=1788448901; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=gfybd4V4UjgdMJm9L9K0Iew+0ete1Kw2IvE21GRtIMc=; b=QMwC4SNjr73NRYU1CIYYo6vuJYmVX2fWcgH8JiUcxR99XDgAKR6oyh2J0xM9RBJ405 4bmixBZIxxnHdj/ZQgWQXaqwh3yEwtt9kZfv3Bl6qtoRBtBHeKcISIOzoKnf1rmV8psb DqBnwXpvugESRp4rGIEAahtBpZynJl5Xh/kMpyS6BKvQIl1cAdDXMS4mlaYbOOxFY9vT G4FHbssgQ9Ywzau/BIJyAgAcrQLoafvNpJAnhgRr644r4yxKn1pTvXKnLDnxz+w5wJQB BW9txvlJ/7TEUHjt1NGLsXCbnoHw/Vdni62sVrpMJXVNoP9Fe/ZH2F2QRXjHMr84jMaL pDYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844101; x=1788448901; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=gfybd4V4UjgdMJm9L9K0Iew+0ete1Kw2IvE21GRtIMc=; b=U7l2Dnhma4Evc93WhSXm6DpvipnvALORA4HHd4rcgNlWaxZUnDSGBtxmRCHJiT8uyn Jgc087gtGkYZQWlpFcIHqEERhuS6L7VSNxFjfdT+gFhKVBI/2jBL+ynzxIaxb7a4qZ6f 1J/ekPVjEAYgzFPAhYJjKMjNWu5ZnIIFDxGo4Hxme3RUPdFt/1yFbTcGR9pthBJY2y/p foOJCBs+uY/fPhJrQ+1965z1Ut8xs1OcbAWiB2grDc8yz6c0t3qEogmxwjX8NFLKP7Vy /i3ePnJCRTrOWMv5c08FM9B0QvXZPoVeC2SKW4YKSDyQlkaP6pC0mxO+WNAgoFSH9mQZ 3pKg== X-Gm-Message-State: AFuF++m6tuLomDS90dsYOWSlx6rLzg4LEKBzxe4RbIzf3i2RYK1KzLip yvK8xFreGXceW9ntSAQfQ88pgwOojBfljL4OdVOUrhAlj24kMLOnjemPItnDcQ== X-Gm-Gg: AR+sD12k+MWLiqqDgjEuk/CbZQzBdwOIsITkz9MexsY+Nr8MBnQU+81sQH2dhLwMISF aj3Pr28bdyYKd+SFE9m3NAog28kHclFEBQgYPPHEEMbL2eK1gDsGxchnw3qmWbEW1ce3MnPUH76 UYg4tKmF2Va69t03JatmrB1vxVgwviZaSdRdtj+365IkcOgz0x0A/r0o3Y96R9S9FnyJb5+YLB3 +gN+BqEBHAiY8+vnIZPL7QJw0KxA47wEjWVRh/3qf6YT4vt8SrcLSC+4WWeNLoSQWNbakUDRAfV 3EgGEHy4dwOwaBzUn5cURhJ6v7c7GV6e3e8aGTYDd9Liku6775XuVbfrRndsS1iry7FyLXE+5Qc 4YAItn6BCRhOPLw0RxQ3W7Abwq/2szWzP67HpZCYBVCmipa+zCoyE67S8bIwtFNXP59ewZRcnjZ FJGFKcE58viADfwZKD0DxvoZrAlt+2HYnHV6s5XYa8PhsYHZr1bs4ChzoP/uv6sM1Rq8Gze0ynp yROPEoWg+Oe9hQ7NZ28EL/rNsozhwKXnpoo41cUvNAH X-Received: by 2002:a05:600c:3554:b0:499:b65d:124f with SMTP id 5b1f17b1804b1-499dc71ea96mr144658435e9.11.1787844100696; Thu, 27 Aug 2026 08:21:40 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 01/39] xen/riscv: drop pregs from struct cpu_user_regs Date: Thu, 27 Aug 2026 17:20:45 +0200 Message-ID: <0dc967fc4bba2dfd97a9c9ea6e60e4d5be3538ff.1787838835.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-ef75cf/1787844101-344CBAE4-94184493/10/73395122804 X-purgate-type: spam X-purgate-size: 1482 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844128120158500 Content-Type: text/plain; charset="utf-8" As nothing is using pregs in upstream or downstream ports of RISC-V drop it from struct cpu_user_regs. Once it will really be needed re-introduce it. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich Reviewed-by: Baptiste Le Duc --- Changes in v2: - New patch --- --- xen/arch/riscv/include/asm/processor.h | 2 -- xen/arch/riscv/riscv64/asm-offsets.c | 1 - 2 files changed, 3 deletions(-) diff --git a/xen/arch/riscv/include/asm/processor.h b/xen/arch/riscv/includ= e/asm/processor.h index 6b89df4a2d4f..b1745c107100 100644 --- a/xen/arch/riscv/include/asm/processor.h +++ b/xen/arch/riscv/include/asm/processor.h @@ -50,8 +50,6 @@ struct cpu_user_regs unsigned long sepc; unsigned long sstatus; unsigned long hstatus; - /* pointer to previous stack_cpu_regs */ - unsigned long pregs; }; =20 /* TODO: need to implement */ diff --git a/xen/arch/riscv/riscv64/asm-offsets.c b/xen/arch/riscv/riscv64/= asm-offsets.c index 472cced4f8af..1290b9dbbe82 100644 --- a/xen/arch/riscv/riscv64/asm-offsets.c +++ b/xen/arch/riscv/riscv64/asm-offsets.c @@ -50,7 +50,6 @@ void asm_offsets(void) OFFSET(CPU_USER_REGS_SEPC, struct cpu_user_regs, sepc); OFFSET(CPU_USER_REGS_SSTATUS, struct cpu_user_regs, sstatus); OFFSET(CPU_USER_REGS_HSTATUS, struct cpu_user_regs, hstatus); - OFFSET(CPU_USER_REGS_PREGS, struct cpu_user_regs, pregs); BLANK(); DEFINE(PCPU_INFO_SIZE, sizeof(struct pcpu_info)); BLANK(); --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844123; cv=none; d=zohomail.com; s=zohoarc; b=ceg5pkP4E/eqiRPkr6JP8LIHPl/1diZg4sZh66O0wNXyT4AA54Zkmlpeqmf5AtuQG+ywQouMuAT4UyGLWmGuQPtrW6EGEh27Dl2Vdo/YyOwAUmT41i6HS2vIsdzasvTSsE6qr4QcdkISe0GUcgxN1EGFYllK+59QA+BgL004epc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844123; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=4qR4ZxxdmOnoURFzE5SrYlUJhLSrYR8G42wvDz6STVk=; b=LvfUBka3FEyPvCsLQIAdw5D3JhNE8qsjvfmI/P4sU+3nKw6L41B4v0mkhkG517WuKmY+LIEUW5w6jegRwOwW8NYCEG02b4AylIbMj4zXYlvm3crjfKKd/AbQR6h9kJot9+IY7UsiFZ/Rr4X8WAxHGlEEZQkcuObIlZ0SFP9LGgs= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844123880150.47276652169273; Thu, 27 Aug 2026 08:22:03 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400921.1636553 (Exim 4.92) (envelope-from ) id 1wzbvE-0006JW-26; Thu, 27 Aug 2026 15:21:44 +0000 Received: by outflank-mailman (output) from mailman id 1400921.1636553; Thu, 27 Aug 2026 15:21:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbvD-0006It-UA; Thu, 27 Aug 2026 15:21:43 +0000 Received: by outflank-mailman (input) for mailman id 1400921; Thu, 27 Aug 2026 15:21:43 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvD-000699-3M for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:21:43 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvC-009ktn-GR for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:21:42 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a905605-e002-0a2a0a5209dd-0a2a4506aa28-2 for ; Thu, 27 Aug 2026 17:21:42 +0200 Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a905606-195a-0a2a45060019-d1558030b16f-3 for ; Thu, 27 Aug 2026 17:21:42 +0200 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-499ae1c6471so14450135e9.3 for ; Thu, 27 Aug 2026 08:21:42 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.21.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:21:41 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844102; x=1788448902; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=4qR4ZxxdmOnoURFzE5SrYlUJhLSrYR8G42wvDz6STVk=; b=kggq/C6VqivoXdf3/+jqJ9G7y3U/qTYoF4LAdveYN/BgtI9PECFIICIM2gbjPLJj+6 si6kPjgJ2K0ns14KkgqfHRm4z786E+RfOsOUKP8iLkNZDTEn2BHfBDK4dbU1SkmWE4Og QH9DyGm69QB2DMjxcJt86Opa19lYWMm7TByKQZbrApAxBiJWHv8ZFpuJ+zQCzp7eYuGk UuODjMBwDzjbbTe52KIxeAqo6/jV8vdb32jBURsqp9vCzcfsXJ0ns9gMx1TY5g8+n4MC L/UcbWoQSSsoJqAM27UvrCRBOAUhNHmkw9KX0yNWqPcaydEqHBRPs2XvjtP798k3AoTt ftFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844102; x=1788448902; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=4qR4ZxxdmOnoURFzE5SrYlUJhLSrYR8G42wvDz6STVk=; b=Ez09m8sFE0+8SKhWwmFp6zNODbHRKtMck083adNaJIE1XhY9vS39baYNeMUr9Jp0UA 10SnHdFc+NJEbtFGjClDvK2VMPAmn89nIKSKVZ1QRrqd2EzvW+YjzkX10R/jftgJqiWA LNFK9IcZRMj9ALyBNUelyqVpQtXnJgoD/IT/NDuzdMUPyq9S3u48xdryWFGYOH4o56rl BH71aInXVy70j8lSJi9MmRc5m6XhQ69JYhExB4GueO9xNVIlmozZWO2MsWiPhUJlkxN7 Ta7EXPAcGaEoyT8yHq22l801KmJKqpUqf/gvL4hZUxc1ItXw1Ry+itKO4VkuSnYk7C4P whkg== X-Gm-Message-State: AFuF++nDtNc+FoND+iZFL8dXUlfN7ujqtmxWpusNvA6OqZranUihPrb3 l4iMY5fABK/ZAWhcUFFpXMUSZtV3p3Fhg1jgj826FBwYmu+Gd8CdeQdR9Ufliw== X-Gm-Gg: AR+sD13UOsRK9TeqocUwpnLyDcbc1GlYKgk7RSnZIO68DW6Ujp6aVJKeIEnKxAwUn9A gLBKEIOAcBc0XWy9vMAZz33fEhhOSg4tpsdHpURbK4SwTC8rEaDyK1q2OBCuRF5bOYPRakIEBVE 1P5Fb49xCKlvgpmlqXm6efOxoqkLJWbxg4ANlfW43E6CwQ9SBJ5scFbSmEshDX6/XeFH50oXITN CUdU8tXNvES+9t0dKIppsLUnYG/pD7Alq0c+gRSwH+2FLfIT8w5h/qiP9LJ2DvGU4Hbh8LaJZlf OGHtoh305QpjRjo8WoSXGPHsAFR40LJm6Grp9a0akri0L2QC5DALPDz7beJjIudxMc6H5ZxNVrV N4y3Hb8qP1zoOsRyG4fK0uilnG7ld4Jg0zSLgsz0ZeBl168GUeckd2KlLX4HmqMqWfQbOf6LQx6 mw+duFB7aPG5lcEqOhyP0B1mvBfdIGIY7uFn3H5Blk4FTYb8uK0ZOdSgqoKTI43H8hiEh/QbDgT 10+vMVsXRJSadJxMHVeBedgrQAXc1Zj X-Received: by 2002:a05:600c:8b5b:b0:495:4d5c:903e with SMTP id 5b1f17b1804b1-499dc703474mr172481975e9.7.1787844101845; Thu, 27 Aug 2026 08:21:41 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 02/39] xen/riscv: drop bug.h's duplicate instruction length helpers Date: Thu, 27 Aug 2026 17:20:46 +0200 Message-ID: <9908a5b8a5e0d00403af8073a6b7452c19795fc3.1787838835.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-16d1c6/1787844102-1FECC77B-57640B1F/10/73395122804 X-purgate-type: spam X-purgate-size: 1984 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844124091158500 Content-Type: text/plain; charset="utf-8" asm/riscv_encoding.h already provides INSN_16BIT_MASK and INSN_LEN(), and emulate.c uses them, so the tree carried two spellings of the same thing which could drift apart. COMPRESSED_INSN_MASK never had a user. No functional change. Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich Reviewed-by: Baptiste Le Duc --- Changes in v2: - new patch. --- --- xen/arch/riscv/include/asm/bug.h | 19 ------------------- xen/arch/riscv/traps.c | 2 +- 2 files changed, 1 insertion(+), 20 deletions(-) diff --git a/xen/arch/riscv/include/asm/bug.h b/xen/arch/riscv/include/asm/= bug.h index e6f286881662..c2cdc2dc2a46 100644 --- a/xen/arch/riscv/include/asm/bug.h +++ b/xen/arch/riscv/include/asm/bug.h @@ -13,25 +13,6 @@ =20 #define BUG_INSTR "unimp" =20 -/* - * The base instruction set has a fixed length of 32-bit naturally aligned - * instructions. - * - * There are extensions of variable length ( where each instruction can be - * any number of 16-bit parcels in length ). - * - * Compressed ISA is used now where the instruction length is 16 bit and - * 'unimp' instruction, in this case, can be either 16 or 32 bit ( - * depending on if compressed ISA is used or not ) - */ -#define INSN_LENGTH_MASK _UL(0x3) -#define INSN_LENGTH_32 _UL(0x3) - -#define COMPRESSED_INSN_MASK _UL(0xffff) - -#define GET_INSN_LENGTH(insn) \ - (((insn) & INSN_LENGTH_MASK) =3D=3D INSN_LENGTH_32 ? 4 : 2) \ - #endif /* !__ASSEMBLER__ */ =20 #endif /* ASM__RISCV__BUG_H */ diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c index d35c013e1399..8530e6fbda0a 100644 --- a/xen/arch/riscv/traps.c +++ b/xen/arch/riscv/traps.c @@ -214,7 +214,7 @@ void do_trap(struct cpu_user_regs *cpu_regs) die(); } =20 - cpu_regs->sepc +=3D GET_INSN_LENGTH(*(uint16_t *)pc); + cpu_regs->sepc +=3D INSN_LEN(*(uint16_t *)pc); =20 break; } --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844128; cv=none; d=zohomail.com; s=zohoarc; b=YCSSwHesfKwXl+xU86g5kS864GsqvOjJMpUGItlv5LwPcwx6rXRUej0khLwV8nOq+qR5QyTctGlPV3burrupjwh60HqzbMaLhnTQ3eky6IacbrqCACVHfJKrQJjlhL0BTUL+2fPNkQhcz32D1cHFYF6pDy3m+5h4zz6SJEJ2RGU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844128; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=pPn9hd/dxW4y06CkNL4I3sE+dR/SRrFH1F3U453rsZE=; b=asgpYyCRqzs93u+3krlb55BPufCYhEiS0Ygm55LCsQo93dJQ7FJBCjpNc/HN/8UBzUOvt35GeGniUAwJ4zSndyiFBeMUJQ6DgiL+ha/yU47gN4DA8TYLyeO/hclbPualgV2zZPnHE1oCGCJ9u/3FCDpbSON7dpKnT/dnOS9d/DI= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844128683818.9487690765392; Thu, 27 Aug 2026 08:22:08 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400922.1636567 (Exim 4.92) (envelope-from ) id 1wzbvF-0006i4-Ia; Thu, 27 Aug 2026 15:21:45 +0000 Received: by outflank-mailman (output) from mailman id 1400922.1636567; Thu, 27 Aug 2026 15:21:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbvF-0006hO-CR; Thu, 27 Aug 2026 15:21:45 +0000 Received: by outflank-mailman (input) for mailman id 1400922; Thu, 27 Aug 2026 15:21:44 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvE-0006Qz-JL for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:21:44 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvD-009ksf-WD for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:21:44 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9055fd-2eae-0a2a0a5409dd-0a2a45029cdc-14 for ; Thu, 27 Aug 2026 17:21:43 +0200 Received: from [209.85.221.54] (helo=mail-wr1-f54.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a905607-6ca4-0a2a45020019-d155dd36ac20-3 for ; Thu, 27 Aug 2026 17:21:43 +0200 Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-482e5733a5aso1156807f8f.0 for ; Thu, 27 Aug 2026 08:21:43 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.21.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:21:42 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844103; x=1788448903; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=pPn9hd/dxW4y06CkNL4I3sE+dR/SRrFH1F3U453rsZE=; b=iZ7JnqyD32V8P3Cs1pG4IicBwa+Xhx3Txpih/X/+bkRNxvqLJyNBxK1KYWPl0g+ivP SpQ683E05Vj9bB5f9dE80LD5O9qcdA4Fw8teyuZXSFwoOFFJplzwErVXeNGjFMA4bm+u L3ToSghfrfjCmNkYSqzT8wM+leFDuLf+duAP0+jpgnGFntOECO3v9VxMaO5jupk6znSr VHr+a5MrcKGZ0O1lrVsSXVeG3PBAk/NbYU/t0fWVhYA3dLDbD7fPhKUMrwrfotjFcGQn hqZqa197/o2SUgL3X6ISLk60xSICcCxi83DQSW2lDN0MVEm/6ei02p/qZcHcRSY0DRlw FsPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844103; x=1788448903; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=pPn9hd/dxW4y06CkNL4I3sE+dR/SRrFH1F3U453rsZE=; b=L/0NUhWUefDFTzoHU7bQ/FABgcHgMrfLjp07vSx5pRAu8idxRGiEPL6R3vSPQrGV7e T3/WTmfyoeBUxK/evuc2WV4b2vfC8jRibyFGCiUQ8Lw1eIWWZlXDeKVfC9mNhNYtd5hu 2VbFCRilEZyY6Ma2dIie10ath/2k3VXSw2Y8CNdjkG49ueguZEvwuUZCO7iOw3KuAOel QpUrm/ZhVHM3TvZgUdLiXuG3/7Cu6bSe9uV0oGV1mK8d5iPWTwdJknlIx7AIgBTM1UpX dOroRoKk79NxH7h/OQkvSRnYZbWDAnE2WThs0tHvyAwjivWRe82GI8n8rV4i4FZHVBQy YxeQ== X-Gm-Message-State: AFuF++nGrpl486mZltFgzihnHo0Ioq8qILLKtbmIeKOsIJC8ufKhY1Sv 4oM9r4cw0xvPX5p0KYqK010NYmjTw1lvNuIcItHvNZ7L9EqyQImR9zYEFssVvw== X-Gm-Gg: AR+sD13xbCSrmfzb7AvnIhqg8ni4VrqZgigWdnctGTQ+sU5MdDjtcVi4ReWlbEj9Y/h M44IcbXHPBEBrUI/znCgCT8Zd5qZiGIEzCG78p4azE08d7LZNYOCTkrQenP1y31S4S639n+wpUz 6w3htmp1QLJ7LZwal8SmrCKq8xXi6U2yghuVDSSE7VYz5jFFd6MTGIeZv74f5o+JAilDXjGypVy ypXPTpi6v5L8Y3K3kOFfUyVR5+7u6ET11Vu4E2s1Tsnj6DBuic91990DhIhTfa7IVBbjf0FBT/P MVadxNnlsKC7bqIml2so+YCMJxshMP0AcyTDCxQCo2660naRadgwIsr40xuHHMO7WqiiDtdbNLm HxJjk44N/VxZuiR2FY6uabCTQdtflNPdsBvgkho70UywlxxeMjY5M6qV0JwLSvzyuOfJrkZEWqJ pSUfoGBJVIhkFuo0B3G/mOJL7OEeMrgIE88OtKstn/kZrxkjWWV5AWSbPYYiJyNks2R0V6Pb2a4 EXduQ/K9zjOQdnIRsy9ycSLMpGO6GIRG7lyR+Ycit4= X-Received: by 2002:a05:600c:8518:b0:499:a5c8:c6f3 with SMTP id 5b1f17b1804b1-499dc6e998cmr210340905e9.3.1787844103281; Thu, 27 Aug 2026 08:21:43 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 03/39] xen/riscv: set the guest's XLEN explicitly in hstatus.VSXL Date: Thu, 27 Aug 2026 17:20:47 +0200 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-720697/1787844103-F26B72AC-C6CE6752/10/73395122804 X-purgate-type: spam X-purgate-size: 2025 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844130124158500 Content-Type: text/plain; charset="utf-8" hstatus.VSXL is WARL, so its reset value is implementation-defined. Xen supports 64-bit guests only, so program it explicitly instead of relying on whatever the hardware happens to leave there. This matters beyond the guest's own view of itself: decoding a trapped instruction depends on the effective XLEN of the guest, as the encodings which exist for XLEN=3D64 only must not be recognized for a 32-bit one. Signed-off-by: Oleksii Kurochko --- Changes in v2: - new patch --- --- xen/arch/riscv/domain.c | 8 +++++++- xen/arch/riscv/include/asm/riscv_encoding.h | 2 ++ 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index d94652809e36..57c37cb2dfc2 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -88,7 +88,13 @@ static void vcpu_csr_init(struct vcpu *v) { v->arch.hedeleg =3D HEDELEG_DEFAULT & csr_masks.hedeleg; =20 - vcpu_guest_cpu_user_regs(v)->hstatus =3D HSTATUS_SPV | HSTATUS_SPVP; + /* + * Xen supports 64-bit guests only, so set the guest's XLEN explicitly + * rather than leaving it to the WARL behaviour of hstatus.VSXL, which= the + * decoding of a trapped instruction depends on. + */ + vcpu_guest_cpu_user_regs(v)->hstatus =3D + HSTATUS_SPV | HSTATUS_SPVP | MASK_INSR(HSTATUS_VSXL_64, HSTATUS_VS= XL); =20 v->arch.hideleg =3D HIDELEG_DEFAULT & csr_masks.hideleg; =20 diff --git a/xen/arch/riscv/include/asm/riscv_encoding.h b/xen/arch/riscv/i= nclude/asm/riscv_encoding.h index 03e186bcdb8c..c63e5e304691 100644 --- a/xen/arch/riscv/include/asm/riscv_encoding.h +++ b/xen/arch/riscv/include/asm/riscv_encoding.h @@ -68,6 +68,8 @@ #if __riscv_xlen =3D=3D 64 #define HSTATUS_VSXL _UL(0x300000000) #define HSTATUS_VSXL_SHIFT 32 +#define HSTATUS_VSXL_64 _UL(2) +#define HSTATUS_VSXL_32 _UL(1) #endif #define HSTATUS_VTSR _UL(0x00400000) #define HSTATUS_VTW _UL(0x00200000) --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844123; cv=none; d=zohomail.com; s=zohoarc; b=ILyht9OraCEU4dH/OVq6ji5XSwlO6+PCGgDI5iYNZkmjki5vD8UjJu/aNbAjk1wIcFfCLz3Gy/hUtV14JofhdG81o31AWOKPWPOgIIzClfyVCe8bZYhqMlV7S8Qq3Y2LH2XA2+dstJk/hxgCr0iImi/aPm+ZIQ0RNHumr8GU4iw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844123; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=f/dDDGOGzuHSxVauVFneN7dbPUBeZfbUy36RLoY8ZRc=; b=d8VHnH3J0/mkk1K/vUT+PYGAh4RD5etn37QLrmPJFrLnwCPxStV3hqTbCaDqdX0jKM9u2iCtqclHkk6ZGKKxoUWPfJ42WB9AHKRfZCByTueBXgPP3L3EPLKwhY1uk1SJl4hadVFFUQ8cE8gZ5EhZ0s7DHW3NIp1l7e7J9ekDcn4= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844123764248.98043717210237; Thu, 27 Aug 2026 08:22:03 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400923.1636574 (Exim 4.92) (envelope-from ) id 1wzbvG-0006xf-PR; Thu, 27 Aug 2026 15:21:46 +0000 Received: by outflank-mailman (output) from mailman id 1400923.1636574; Thu, 27 Aug 2026 15:21:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbvG-0006wf-M4; Thu, 27 Aug 2026 15:21:46 +0000 Received: by outflank-mailman (input) for mailman id 1400923; Thu, 27 Aug 2026 15:21:45 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvF-0006iX-Ll for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:21:45 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvF-009ktn-2G for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:21:45 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9055ff-e002-0a2a0a5209dd-0a2a450acd1a-24 for ; Thu, 27 Aug 2026 17:21:45 +0200 Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a905608-f2d2-0a2a450a0019-d155802db59b-3 for ; Thu, 27 Aug 2026 17:21:45 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-49557167508so8907035e9.1 for ; Thu, 27 Aug 2026 08:21:44 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.21.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:21:44 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844104; x=1788448904; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=f/dDDGOGzuHSxVauVFneN7dbPUBeZfbUy36RLoY8ZRc=; b=ONTB6H+fcHwB2j4+vuP4upJ/bl3a4QDOAvTdqC7oiRT31H4GQZ9JpUa3HkmOMcx7Ct mGVqGkIQu2Os5RIRwx15vjUZYOP23FFngdDrkutWRUqz+HOLWUdUPe6SJMD8zuuYPcYq 6+di/b28KUssTLVTw/OPFV8FULv00FBCJW1jV6k5i8+RQDtlZ2yd/hzq8Hr1edEED4V8 rQyBrWFgpA2/UTTMBY2cNRUlo7pNS3RPTWtRm2o0ajD4Xn27FOmTAC3qE+pv4ymJQd2n 9YIMU34fX6Tt1vMdrGmki61d72Lty+tac1xQ4RbM7Gz6YD+dsn+M1LkQ7kOAvqgyBF6W roiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844104; x=1788448904; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=f/dDDGOGzuHSxVauVFneN7dbPUBeZfbUy36RLoY8ZRc=; b=WufwjoGfX4M2PIDIFjGpJaITrwAeoquDTF0t2dtWoL3tHgOqveIryDZiDePZhv9hQc OpRXEEWKL3kg/jEINCK6byjrKG7SDuxXV9o9u5ofe4tTQ0nrJIO6JoSg73+irgptrrrg mP44HVzIfQCluPo370NuXsSiL9gaLhAt4v1HTORHd8OoI+KFwx2rvLspn/rtnuOmb0F9 LLmSYFi6xubDibu9+ILmkydNSBfb0jvY/HMn/ABuvZ7hKxGRhLv+RU11sgQ+hThqvs55 8i6wChyw5LP0WE7SiOB0gh0Kua1RJc3rUaCnO0IPhsPt//pFN9DJtwPd/t7+jngcrKIi AU4A== X-Gm-Message-State: AFuF++kVbhJplK0OdpartvNDgtd3zQTjIfDAq2Szn4+7Usdm+Vovh9UQ h9LNV7q9TqueqNtSs/Oks4/n5dBiJbWrbjqYVnJr7uFBOVMP2tQz/7zIr7ancg== X-Gm-Gg: AR+sD10673tTbvAaM13niSOm1518B4B9FabcBunxz4l/n1uhbbg4gneYqD0RuLVycNu KGbaefJ0n6UC3ch95HVGVpAyzWGTKX5Isex57LahURowN70lskQSfUrNkaT6NeZH0S32kynECCl RjG7AO/0GGil1gaC5rm+/noY6i7yW/5q6NO5yfTDz1qnhdOJzqiP8klMxyMKzcI8G+doq9RTEhn okG8ceJf/tnRXb7OUp6dJvOpbe08kPvNKMwD1oiWk+ecfqi5HN1+oBdbyvyNrr4vsJmD8PcY0cF ARqnGngXKZeH/+z+36KJizh6NkNUC5uoJt4yqtfRDpG1teJEF/q5BuMXBGxA5L5oRsx6Wk/6xX/ 8UU5KCY8ciN0EiWZsIytJ/bzyMsvML0TObEQJFbovWKUGoDzbrRMj7GXyhFmPoSbqOzc0bEfSPd /twK3Jh4wysNm1fsPkfVGjlHOpTt4ikFM5OLSZMU5fwk4FeFG5AexaRKM60QyXoV/dMeSENoFlo EFzeXghQtxlTXnU+78/0d+2domGbpOu X-Received: by 2002:a05:600c:3513:b0:496:bbce:fc with SMTP id 5b1f17b1804b1-499dc82c0d7mr189600475e9.12.1787844104437; Thu, 27 Aug 2026 08:21:44 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 04/39] xen/riscv: introduce csr_read64() Date: Thu, 27 Aug 2026 17:20:48 +0200 Message-ID: <0f7080ea4dc86a8bb3dae39d94e5b03e95d010c0.1787838835.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-4011c0/1787844105-510C9CFC-985064EA/10/73395122804 X-purgate-type: spam X-purgate-size: 3037 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844124099158500 Content-Type: text/plain; charset="utf-8" csr_write64() already hides the RV32 split of a 64-bit CSR into a low and a high half; add the read counterpart. Reading the two halves isn't simply the mirror of writing them. A CSR which hardware increments can carry from the low half into the high one between the two reads, so a plain pair of reads can produce a value the CSR never held. Therefore the high half is re-read and the sequence retried if it changed in the meantime. Use it for CSR_TIME, which is exactly such a counter, and widen cycles_t to uint64_t. Otherwise get_cycles() would still truncate the time counter to 32 bits on RV32. Fixes: a541ddadec0a ("xen/riscv: introduce time.h") Signed-off-by: Oleksii Kurochko --- Changes in v2: - New patch. --- --- xen/arch/riscv/include/asm/csr.h | 24 ++++++++++++++++++++++++ xen/arch/riscv/include/asm/time.h | 4 ++-- 2 files changed, 26 insertions(+), 2 deletions(-) diff --git a/xen/arch/riscv/include/asm/csr.h b/xen/arch/riscv/include/asm/= csr.h index 888d6a2a86d6..a5cdd6f99c8e 100644 --- a/xen/arch/riscv/include/asm/csr.h +++ b/xen/arch/riscv/include/asm/csr.h @@ -39,12 +39,36 @@ csr_write(csr, v_); \ csr_write(csr ## H, v_ >> 32); \ }) + +/* + * The two halves are read by separate instructions, so a CSR which hardwa= re + * increments can carry from the low half into the high one in between, + * yielding a value the CSR never held. Re-read the high half and retry the + * sequence if it changed. + */ +#define csr_read64(csr) \ +({ \ + uint32_t hi_, lo_; \ + \ + do { \ + hi_ =3D csr_read(csr ## H); \ + lo_ =3D csr_read(csr); \ + } while ( hi_ !=3D csr_read(csr ## H) ); \ + \ + ((uint64_t)hi_ << 32) | lo_; \ +}) #else #define csr_write64(csr, val) \ ({ \ csr_write(csr, val); \ (void)csr ## H; \ }) + +#define csr_read64(csr) \ +({ \ + (void)csr ## H; \ + csr_read(csr); \ +}) #endif =20 #define csr_swap(csr, val) \ diff --git a/xen/arch/riscv/include/asm/time.h b/xen/arch/riscv/include/asm= /time.h index 4d68900151a7..ec771c3fe80f 100644 --- a/xen/arch/riscv/include/asm/time.h +++ b/xen/arch/riscv/include/asm/time.h @@ -18,11 +18,11 @@ static inline void force_update_vcpu_system_time(struct= vcpu *v) BUG_ON("unimplemented"); } =20 -typedef unsigned long cycles_t; +typedef uint64_t cycles_t; =20 static inline cycles_t get_cycles(void) { - return csr_read(CSR_TIME); + return csr_read64(CSR_TIME); } =20 void preinit_xen_time(void); --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844132; cv=none; d=zohomail.com; s=zohoarc; b=LHAOFUSWQCSf9ifZiD6H741FH0oL+Zcuj+t0RbMCVzMKajYT+86kxnxsXu5olLY79pjJTKRQKePYpZVjxTi8kBxHWy287oZIm5fgLS1hv5CiXG4gl9vfQTGo4SAAzpjf6R1Fys3qtiSm8QTFvWOelo8n2L+t4ICbFgXpHvejFu4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844132; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=9NLphW7/uU1TryTD93UTmTbn1sjPPFV/Ulb6E16emTQ=; b=lXYGZd4TcNLkYJQGgazKjMGaDB2Rw7hwnN4owed6Hl98GJFuEQ56J5d4RbVT/SGePh2t3FH6l35WwPkrL4qH7aoN+2z/6LfnK95xgZIdFCHFz1dDIWOzI56F3yW6H/Wa2XNXV+Wsevmfz4tg8hfG/3jOV+SJCUz3+5uGVSHGPDk= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844132140523.7488300935931; Thu, 27 Aug 2026 08:22:12 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400924.1636585 (Exim 4.92) (envelope-from ) id 1wzbvJ-0007F5-4u; Thu, 27 Aug 2026 15:21:49 +0000 Received: by outflank-mailman (output) from mailman id 1400924.1636585; Thu, 27 Aug 2026 15:21:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbvI-0007Et-Um; Thu, 27 Aug 2026 15:21:48 +0000 Received: by outflank-mailman (input) for mailman id 1400924; Thu, 27 Aug 2026 15:21:47 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvG-0006xr-Vh for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:21:46 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvG-003Nrj-CA for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:21:46 +0200 Received: from [10.42.69.8] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a905600-8faa-0a2a0a5109dd-0a2a4508e25c-14 for ; Thu, 27 Aug 2026 17:21:46 +0200 Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com) by tlsNG-c1860d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a90560a-f659-0a2a45080019-d155802aa96d-3 for ; Thu, 27 Aug 2026 17:21:46 +0200 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-4954a9e8490so7056565e9.1 for ; Thu, 27 Aug 2026 08:21:46 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.21.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:21:45 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844106; x=1788448906; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=9NLphW7/uU1TryTD93UTmTbn1sjPPFV/Ulb6E16emTQ=; b=UQ928S63TwKFk8ztokSK7Jg89p+UkM/o+xpwihnpjdo8KtI7v8e05VZ0b6E0Oj/Ppb FbemLQS8MK3ub9mAcWeq9xlDHQKHG2OJhWL65FcewyeGgoUXo5uK0kkL2Ddmpq+/Cym1 ZOmvdQT4BM0Ll+yqN4tbePXv/y9BuRrMCtCa0oslmGJ/KQac54Okc9cUYqYBJHZ6S9TF UYn48wKv+y9uGiORlYyHmsspJ/WirV2/AN19F8GSYvTcDxq4Lrn53yaZ3b8OvJslglG7 edW0V20pawXwrhSXLB+GVI2Dx3/GhjRbVZTwamgFkBhcN3WWJSaDRcPmTThYpZJ0IZFp pCTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844106; x=1788448906; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=9NLphW7/uU1TryTD93UTmTbn1sjPPFV/Ulb6E16emTQ=; b=gP5zR/4WUFOEQRqfubLXWhHvPnbjxehmiaPslgYiPxKa0bFsMQ3wF00Xks7lVyRMUF CpXMItc02XAl+l9KsGbq2wvFh1K9Uhol4SqjHFbs7U6vfwqdHfBoJJVzpGwQBsn340rQ 4Ng/n/hy0daLng5eZFBaNziwI5+iigWnGU7qxN4gwleIw/CKnOG1ejtp+vobu7zG4Sii 8T8PdovXg5/901K1bNFjgF5Dy8tZ2ejlwRVmTomqv+IdOwk6YnKGbi5VPWNSpOg4e48H 0M7PZ8goco9DqNtHgB3Sk2Y+7aoDUUnDyQCuAwscgnqKZ3UIw6VU8vn9eErSW3Gvis1p +gBg== X-Gm-Message-State: AFuF++mn/qQbmOGFNxBVcjJ+3TawZSQLDtktUxUEQmqIsg4A1tpHw/mT 3tu3YVIf1IMfLyzraU9QakoEdJtFgJXURjuLLA4Vxu1XkSCR6vgySgp80Q2VXw== X-Gm-Gg: AR+sD10smfo4LENKIsmu7eJYTGnEjXa2AsE+/ldRPYZSyUkAalnmls9PXqTbKtLMUGP j6Qje/+1809ycIN4gs+To1oC8v6SKEHb10uHYQ3/9pjSQgBa2wjQZQa+T/JuEHE18WwyP46IJWl OqlJa4+MPO7PnfRru/BEZGJWudCDCvBDHfNztngc/ACnLUOUwFC14funrEV9xjQxwbcWaLvXkHQ yamX5EGLYerbf+jA/ryLVqT0F4mGzZQTyc8rIiuhwepihUwfufJN0rvSOAUyuMKCrnIwvSIuyau bY8ROsRDU44fw+jW468ix02qyJjWvTrDIstt1C2/AdTssNXmbIgfN139YkgLIoXqQlGUkqhvAjy 7eWGNnsTLHH8zUhYbyPlonbTDkXzFEfOfHO1VGXOdwXcoK/e1/4EkR/WLMif1JHFclTVyykFuwl 0uIlmxDbIGZGtRA0WUOgbC5TNU6qfZmTru4kpN4b2coOoLe/BQcIEw1Gkoe9MmkPaP8xf207nlM q3Q0SABcoR21fUtO2nDVMGmTadsnvsi X-Received: by 2002:a05:600c:1c06:b0:49b:8f5e:51fb with SMTP id 5b1f17b1804b1-49b8f5e52b1mr55532835e9.3.1787844105703; Thu, 27 Aug 2026 08:21:45 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 05/39] xen/riscv: request a G-stage flush on vmenter when VMIDs are disabled Date: Thu, 27 Aug 2026 17:20:49 +0200 Message-ID: <4274740481062ef92a76debd9c3f1e8371858735.1787838835.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-c1860d/1787844106-DF6D687B-ADA8C687/10/73395122804 X-purgate-type: spam X-purgate-size: 2277 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844134162158500 Content-Type: text/plain; charset="utf-8" vmid_handle_vmenter() reports that no flush is needed when VMIDs are unavailable (vmid=3Doff, or hardware with no more than one VMID bit). Every domain then runs under VMID 0 with nothing flushed in between, so as soon as a hart runs more than one domain, a domain entered there can use the G-stage translations left behind by the domain which ran before it. Adjust the comment in p2m_handle_vmenter() accordingly: skipping the VS-stage flush no longer relies on an old VMID not being reused, which doesn't hold when there are no VMIDs to begin with. While at it, spell the other early return as a bool literal. Fixes: bff3b9ea4696 ("xen/riscv: introduce VMID allocation and manegement") Signed-off-by: Oleksii Kurochko --- Changes in v2: - New patch. --- --- xen/arch/riscv/p2m.c | 4 +++- xen/arch/riscv/vmid.c | 4 ++-- 2 files changed, 5 insertions(+), 3 deletions(-) diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c index 1cea86512c8c..de25607247a6 100644 --- a/xen/arch/riscv/p2m.c +++ b/xen/arch/riscv/p2m.c @@ -1584,7 +1584,9 @@ void p2m_handle_vmenter(void) /* * There is also no need to flush the VS-stage TLB: even if speculation * occurs (VSATP + old HGATP were used), it will use the old VMID, whi= ch - * won't be reused until need_flush is set to true. + * won't be reused until need_flush is set to true. When VMIDs aren't + * available there is no old VMID to rely on, but then need_flush is s= et + * on every entry, so the flush above covers that case. */ } =20 diff --git a/xen/arch/riscv/vmid.c b/xen/arch/riscv/vmid.c index 11c7e9d6d6c8..93714b359534 100644 --- a/xen/arch/riscv/vmid.c +++ b/xen/arch/riscv/vmid.c @@ -141,7 +141,7 @@ bool vmid_handle_vmenter(struct vcpu_vmid *vmid) =20 /* Test if VCPU has valid VMID. */ if ( read_atomic(&vmid->generation) =3D=3D data->generation ) - return 0; + return false; =20 /* If there are no free VMIDs, need to go to a new generation. */ if ( unlikely(data->next_vmid > data->max_vmid) ) @@ -164,7 +164,7 @@ bool vmid_handle_vmenter(struct vcpu_vmid *vmid) =20 disabled: vmid->vmid =3D 0; - return 0; + return true; } =20 /* --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844127; cv=none; d=zohomail.com; s=zohoarc; b=h7or5B/AeKtH1ZYr1LeuKctW1Ml4w32qnz5sExX/VohL3z/aY+oECMB+4H7naDbGlwPMTR2Mka/cmUjB1z2m7REPbqp1pMRzQ0PI0pYFC5VYB2+zoDiRKyv6+gnSPr3FKZPlnU+eDWETb6mrfVKz1poR1cfNK12FhN+CTFE4eP4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844127; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=f/PHkzPjuuueFQEDbht4GQqNTPSC6pSyUCZiwcakFlI=; b=lHqVsF4qDZh53unpm7SL2z+0tUfxPQ7BSImo5WpBDOEngAfN5PpVhdDhlDYj7Fy0IgYbeVXr9JTTT1w0qhnikwhHEijOrfgBOGMtL27o+AuX+LOrTfqfw467KDUxlFSuW7cNNUWtP1bKu9q9cAtoWZwoHA/Pka426vk/B84iszU= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844127006567.026985251004; Thu, 27 Aug 2026 08:22:07 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400925.1636589 (Exim 4.92) (envelope-from ) id 1wzbvJ-0007IJ-E8; Thu, 27 Aug 2026 15:21:49 +0000 Received: by outflank-mailman (output) from mailman id 1400925.1636589; Thu, 27 Aug 2026 15:21:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbvJ-0007Hn-80; Thu, 27 Aug 2026 15:21:49 +0000 Received: by outflank-mailman (input) for mailman id 1400925; Thu, 27 Aug 2026 15:21:48 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvI-0007E9-NQ for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:21:48 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvI-009ktn-3z for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:21:48 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9055ff-e002-0a2a0a5209dd-0a2a450acd1a-34 for ; Thu, 27 Aug 2026 17:21:48 +0200 Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a90560b-f2d2-0a2a450a0019-d155802fedc9-3 for ; Thu, 27 Aug 2026 17:21:48 +0200 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-4998b5a63e2so21329235e9.1 for ; Thu, 27 Aug 2026 08:21:48 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.21.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:21:46 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844107; x=1788448907; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=f/PHkzPjuuueFQEDbht4GQqNTPSC6pSyUCZiwcakFlI=; b=XeaZQUHvcgIMXaRPZ9PVtrHNfvsivPMMVlSwf8i7foGR93SHmxmS/BtMAgCCfRh/bl ASvBlzRFm5nqbyyvuZMBlFhb6LnZ0E65i89Wb+7TwEOncYswDz+//8dxfA7XQzvAvL+0 TmIHMWp2Nx5IsJkj7Z/bxvi8jFv7ty1jNCgIORY2Hpq7b7uptnbSkn6ZJYJ6DOjI2FGG CEoGy7upRwVW+WxTYv3k4+p4MZuwsqQcj+vniN6jvgIufKoWKj9u+MXqyZ1FbxKR9H6s JR04C9ygA6HXDkcCK9FgJKdLWZrenoBX2PbwJl9Whye1cAscnnew0jBv193NywUvNzDX ptbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844107; x=1788448907; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=f/PHkzPjuuueFQEDbht4GQqNTPSC6pSyUCZiwcakFlI=; b=OqBV+YebLWX7hziV4kzA//my2VO3SiiPOggDCaVkZ14IFbAZ2fda4exb600JtMQKNx nc37kCu3oVacEQZ4D4Gr0tDhCQLsX+FzZLHAsC75XppPQzzXny4M44rNwxrA4Bq2DBNP AUxilbdKeBR2IGu/8rIqtLWv3MYEdfTzeOP7WibtKKWGkSr1hE4PXzAs0PltqbDCUNkx R5AM57yQPP9MwcHLnoC5M/tVkeTIuMhtUa20NQtK46yHZYL0/VpclwNscyUD6kvPNLLU /iUdE0ZTaTZdt68NcnN7ijiIDU7H62BUii7NTjl9cFhjYukIiVk7Y6SdNmWPuTPHKb8G 4nWA== X-Gm-Message-State: AFuF++nOhKRz//5p6Dw0TGgk1AeJx/yZw0WaCYvjB24j54qW5unWp0sb hBw4qARh9ZauMQVXABkGseqhsXNDT77DBXu6Op1gKPB6zoSAWB7TKi0Hu3DbMg== X-Gm-Gg: AR+sD13L2yf3P13J7tAVJQMFFBU7inPsVB7BWr3pleofcqmODTE2Ijoa53HQdt9DJkM ANOEZtZ5lC7+xlooUwj5sRZyrK4giV0Srh/TDw4s0Ea17H8lFSQxulGJgqFbC6OAQz69M6X23nt T2PMQYbpR5mBvdfbDDuo6q3GaqZ7uv4KyE1dJQMw6UmaNaEarsVB34kSM5RB9hbLKm5lz0vwWuP qxbjW7q/DygVFC9LP1iDHD01yYRsQuszwM9/nP6PMuspoKPNI2pR6psM+6ak7jpTD37TUAzM6eQ Mp0nHoT6tHarfQ5rgMMUfXQy+KeoAdA0MyXd0Cnq+oStFR42KfX6a9ONbFHRi/ekZ9I68DuXvib 6FRX7kCQISFKOamGO0q3orHtQQYvQvCks4DHSlqCNn57Fd9jQ5tgcpgT8NQwm82Icv7AuqYU0II 2h4CFJOBzjcX8Zl8zwIyOOKNtsW4aGE0+DjT1JUCAzeGiW/E/a4pPTCf9FRe17zKh64c+bEfcr6 yeLdZ3Ul63tdRmXeLI2pCUoTb9AKQUNT/BT9bFYc6U= X-Received: by 2002:a05:600c:1d15:b0:49b:d45:703e with SMTP id 5b1f17b1804b1-49b0d4570b4mr123481185e9.8.1787844107010; Thu, 27 Aug 2026 08:21:47 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 06/39] xen/riscv: use UINT64_MAX to disable the VS-timer Date: Thu, 27 Aug 2026 17:20:50 +0200 Message-ID: <93829c39b080d288ea342c7375d5307f93ee9a29.1787838835.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-4011c0/1787844108-518C5CFC-04893859/10/73395122804 X-purgate-type: spam X-purgate-size: 1505 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844128123158500 Content-Type: text/plain; charset="utf-8" vstimecmp is a 64-bit CSR independently of XLEN, which is why it is written with csr_write64(). On RV32 that macro splits the value into the vstimecmp/vstimecmph pair, so passing ULONG_MAX (0xffffffff there) writes all ones to the low half and zero to the high half, leaving the CSR at 0x00000000ffffffff rather than at its maximum. A VS-timer irq would then become pending as soon as (time + htimedelta) reaches 2^32, which is exactly what the code is trying to avoid. Use UINT64_MAX, which matches the width of the CSR. On RV64 it is equal to ULONG_MAX, so no functional change there. Fixes: 25e032730690 ("xen/riscv: allow Xen to use SSTC while hiding it from= guests") Signed-off-by: Oleksii Kurochko Reviewed-by: Baptiste Le Duc --- Changes in v2: - New patch. --- --- xen/arch/riscv/time.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xen/arch/riscv/time.c b/xen/arch/riscv/time.c index 602c029641b8..8c25198b4063 100644 --- a/xen/arch/riscv/time.c +++ b/xen/arch/riscv/time.c @@ -101,8 +101,8 @@ void __init preinit_xen_time(void) * A VS-timer interrupt becomes pending whenever the value of * (time + htimedelta) is greater than or equal to vstimecmp CSR. * Thereby to avoid spurious VS-timer irqs set vstimecmp CSR to - * ULONG_MAX. + * UINT64_MAX. */ - csr_write64(CSR_VSTIMECMP, ULONG_MAX); + csr_write64(CSR_VSTIMECMP, UINT64_MAX); } } --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844132; cv=none; d=zohomail.com; s=zohoarc; b=ej4UMxf6NWvMRJ2HtzkpAcahuch9spsEB59dovdFyDq/AxSUi+N5M0Ko+kbVSnxZHWRDox8PbZrson2nicUo+BmI2sXiZgsE+unVocK3DuGV/oPTGTyX9jpGjSW9Ez30QdxfwFDBPtgIKW63AegdxO5WNSLQdMjrq9pCC2zrdxo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844132; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=OcNrz4VvoxOmwdg7GYQ3jroj3OtmNT9ZQb6a2V47tT8=; b=Vitny70DusBFwgLveekzoBlQNPkPvRuWFIVbN2+7giYpeffqwu5KEK58FJT0o7en8ECuv+rEptkJsesv3Blg7fJW1RMzWQY2Dkq/IzRTpmTHEK34KYL/kb5U6TBtjFI4cryv4s4NW0UB0eB7y/rB+vWiW9YljvZb5vdf/V0ImYY= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844132937287.5941312026192; Thu, 27 Aug 2026 08:22:12 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400926.1636602 (Exim 4.92) (envelope-from ) id 1wzbvL-0007ly-Vm; Thu, 27 Aug 2026 15:21:51 +0000 Received: by outflank-mailman (output) from mailman id 1400926.1636602; Thu, 27 Aug 2026 15:21:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbvL-0007ld-Ou; Thu, 27 Aug 2026 15:21:51 +0000 Received: by outflank-mailman (input) for mailman id 1400926; Thu, 27 Aug 2026 15:21:50 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvJ-0007Oe-Rk for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:21:49 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvJ-00FiCE-8G for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:21:49 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9055fd-bab6-0a2a0a5309dd-0a2a4503983c-24 for ; Thu, 27 Aug 2026 17:21:49 +0200 Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a90560d-fae8-0a2a45030019-d155802aad93-3 for ; Thu, 27 Aug 2026 17:21:49 +0200 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-49b0dd3c9a0so9201085e9.1 for ; Thu, 27 Aug 2026 08:21:49 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.21.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:21:47 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844109; x=1788448909; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=OcNrz4VvoxOmwdg7GYQ3jroj3OtmNT9ZQb6a2V47tT8=; b=aeK+tFt0xdiOJHv9qAlGDtqdRMKrxPx/gm+M++ET2KhZEmTDUsVY8LdsEtZzaO09dh fmzPcaNbTeSbW8/hJwoug99HdySRRqthB/efJkBfMwMPdN8o8KWN/XD6XTG0x8BpxmFc H/tmztIxu2KiSckUlarqkpiB41K6NyUQ3sBXuGvOULAHLdc4TMDociak+NHoFI8Qx+8i Ecne27GoLBtwzmx7RGSqsWRSPyR5UooKlfMGZ9eNqp+d4PkBODULSf6+7Qmm7mepc4CO aK4coZLV0apLl6v69IAQkGuyCqLO216ROA1xZFbm07L3WC13/t8DByIV+aX7bT6hhE9i uXvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844109; x=1788448909; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=OcNrz4VvoxOmwdg7GYQ3jroj3OtmNT9ZQb6a2V47tT8=; b=Ut1HUP9083kvNfz8RrCShCcYgHxQAUi6QTTPb4e5ocV56FogOsbChqOeIIPEJ9Ns5e 6ozyiceZz+9/Qxebn4Gam1xjnHCPeZhZxpHpntbX+DiYV/4uhVSTKkhShL/X5IhmZq59 uqrxgh79OWsTH8UjW/WJbx43Mb/VCYIDzRgWyAcnUqnUk8ZC9sPBf/mJC/nBK9pqO29D OlSaizPFpJhWa5QmzGkaK2eXKfZ+ISdi02NoQYPgsi0NERtfQAkMIqvX4tMuOXVjRQ3N bOATHCLwPSAmk2djyT8Ul9U4kicOliizesoA6rXakdJqPw6xD3rv0ouSaldZ+CLmRkoO T4VA== X-Gm-Message-State: AFuF++lvBP1MsyYSnovYTpMB/iLQLy4j/XK6dxXGAmwbxmMBfbuq4WtP NhcZgfaGP7dKaez45PqeTOxXXcXa40/uavEdAYXirG9j2DDAqpEq+cnWPhgOOQ== X-Gm-Gg: AR+sD13vq+FE7DlNqEVgg0+FszAUC2jkFzYJErP+026+UbdlW41k9fYo+X9MY6t89RK J01qUhCNIy4+jERlP6OkDl5N04hrCQaRqcDT115ppz5c2tw8zeB7kB50C1wLw+earRRnziIhX9a J1bt56jz9qsgAeyYUdOmLbnyAqY446JvNV+GNvi2lBkxqFNvF+HtO4M6zuRGf5cvyIwIqexPI+2 0GWggWoGtfjhFTQtB2V9mJDaqCQ6qgiFi8CLswyzmmp1o2DCA4w5WBsZ3zkQ9zkTJl/ZLI4ypj9 CWpgW7lVW1vmJ9CHhfZpK79X3ORKNGrXHnrDzfppoO7LtrT2dfmb+IO4wQRoN2dJWC4CmLiefz6 shGS7+ZarO8hUOxh3Po1eAb6oieGvt6cBPLVQepcvkEk4FJjL82wHMjAA3ZVBNKwNVccFtlm8Zg DWXA+I5h+3BxE9hsWQ28/Drlu15W8lbpqngfAoX4hJXwGtaUv3RzKKd95t70IhgLYNkTHjNm3Mr eHUiSF37Own0jKH4pNjtOhgjgucsvvu X-Received: by 2002:a05:600c:c8f:b0:499:cd34:f7c with SMTP id 5b1f17b1804b1-499dc6f68b5mr163811375e9.5.1787844108307; Thu, 27 Aug 2026 08:21:48 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 07/39] xen/riscv: add missing APLIC register offsets, masks to asm/aplic.h Date: Thu, 27 Aug 2026 17:20:51 +0200 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-33051d/1787844109-6EECA4E9-343351B2/10/73395122804 X-purgate-type: spam X-purgate-size: 5998 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844134197158500 Content-Type: text/plain; charset="utf-8" These definitions are required for correct decoding of APLIC MMIO accesses and target configuration, and will be used by both the physical and virtual APLIC implementations. While adding them, rearrange the header in the style of x86's asm/msr-index.h: a register's offset is immediately followed by the definitions of that register's fields, with the blocks sorted by offset. This makes the relation between a register and its fields obvious from the layout alone, so no comment is needed to express it. No functional change is intended by this patch; it only centralises hardware definitions that were previously missing. Co-developed-by: Romain Caritey Signed-off-by: Oleksii Kurochko Acked-by: Jan Beulich Reviewed-by: Baptiste Le Duc --- Changes in v2: - Rearrange the whole header the way x86's asm/msr-index.h is laid out: put each register offset first and the definitions of its fields immediately after it (indented by an extra space), sorted by offset. - Describe the convention in a comment at the top of the definitions, mirroring the one in asm/msr-index.h. - Reflow APLIC_SIZE() to fit the new alignment column. - Fix the comment for declaration of member target in aplic_regs[]. It should be 0x3004. - s/APLIC_REG_OFFSET_MASK/APLIC_CTRL_REGION_OFFSET_MASK --- --- xen/arch/riscv/include/asm/aplic.h | 90 ++++++++++++++++++++++++------ 1 file changed, 73 insertions(+), 17 deletions(-) diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/as= m/aplic.h index 07318aaac25d..a2af55d54fc0 100644 --- a/xen/arch/riscv/include/asm/aplic.h +++ b/xen/arch/riscv/include/asm/aplic.h @@ -15,32 +15,88 @@ =20 #include =20 +/* + * APLIC register offsets and, immediately following each of them, the + * definitions of the fields of the respective register: + * + * #define APLIC_$NAME 0x$OFFSET + * #define APLIC_$NAME_$FIELD1 ... + * #define APLIC_$NAME_$FIELD1_$VAL ... + * #define APLIC_$NAME_$FIELD2 ... + * + * Blocks of related constants are sorted by register offset. + */ + +#define APLIC_CTRL_REGION_OFFSET_MASK 0x3fff + +#define APLIC_DOMAINCFG 0x0000 /* * domaincfg read-only fields (AIA spec): * - bits [31:24] -> read-only 0x80 * - bit 7 -> read-only 0 */ -#define APLIC_DOMAINCFG_RO (0x80U << 24) -#define APLIC_DOMAINCFG_IE BIT(8, U) -#define APLIC_DOMAINCFG_DM BIT(2, U) -#define APLIC_DOMAINCFG_BE BIT(0, U) +#define APLIC_DOMAINCFG_RO (0x80U << 24) +#define APLIC_DOMAINCFG_IE BIT(8, U) +#define APLIC_DOMAINCFG_DM BIT(2, U) +#define APLIC_DOMAINCFG_BE BIT(0, U) + +#define APLIC_SOURCECFG_BASE 0x0004 +#define APLIC_SOURCECFG_LAST 0x0ffc +/* + * sourcecfg[] register fields: + * - bit 10 (D) selects the layout of the remaining bits; + * - D =3D 1: bits [9:0] hold the Child Index, i.e. the source is delegat= ed + * to a child domain (unsupported by Xen); + * - D =3D 0: bits [2:0] hold the source mode SM (WARL). + */ +#define APLIC_SOURCECFG_D BIT(10, U) +#define APLIC_SOURCECFG_SM GENMASK(2, 0) +#define APLIC_SOURCECFG_SM_INACTIVE 0x0 +#define APLIC_SOURCECFG_SM_DETACH 0x1 +/* Bits 0x2 and 0x3 are reserved */ +#define APLIC_SOURCECFG_SM_EDGE_RISE 0x4 +#define APLIC_SOURCECFG_SM_EDGE_FALL 0x5 +#define APLIC_SOURCECFG_SM_LEVEL_HIGH 0x6 +#define APLIC_SOURCECFG_SM_LEVEL_LOW 0x7 + +#define APLIC_SMSICFGADDR 0x1bc8 +#define APLIC_SMSICFGADDRH 0x1bcc + +#define APLIC_SETIP_BASE 0x1c00 +#define APLIC_SETIP_LAST 0x1c7c +#define APLIC_SETIPNUM 0x1cdc + +#define APLIC_CLRIP_BASE 0x1d00 +#define APLIC_CLRIP_LAST 0x1d7c +#define APLIC_CLRIPNUM 0x1ddc + +#define APLIC_SETIE_BASE 0x1e00 +#define APLIC_SETIE_LAST 0x1e7c +#define APLIC_SETIENUM 0x1edc + +#define APLIC_CLRIE_BASE 0x1f00 +#define APLIC_CLRIE_LAST 0x1f7c +#define APLIC_CLRIENUM 0x1fdc + +#define APLIC_SETIPNUM_LE 0x2000 =20 -#define APLIC_SOURCECFG_SM_INACTIVE 0x0 -#define APLIC_SOURCECFG_SM_DETACH 0x1 -#define APLIC_SOURCECFG_SM_EDGE_RISE 0x4 -#define APLIC_SOURCECFG_SM_EDGE_FALL 0x5 -#define APLIC_SOURCECFG_SM_LEVEL_HIGH 0x6 -#define APLIC_SOURCECFG_SM_LEVEL_LOW 0x7 +#define APLIC_GENMSI 0x3000 =20 -#define APLIC_TARGET_HART_IDX_SHIFT 18 +#define APLIC_TARGET_BASE 0x3004 +#define APLIC_TARGET_LAST 0x3ffc +#define APLIC_TARGET_HART_IDX GENMASK(31, 18) +#define APLIC_TARGET_HART_IDX_SHIFT 18 +#define APLIC_TARGET_GUEST_IDX GENMASK(17, 12) +/* Bit 11 is reserved and reads as zero */ +#define APLIC_TARGET_EIID GENMASK(10, 0) =20 -#define APLIC_IDC_SIZE 32 +#define APLIC_IDC_SIZE 32 =20 -#define APLIC_MIN_SIZE 0x4000 -#define APLIC_SIZE_ALIGN(x) ROUNDUP(x, APLIC_MIN_SIZE) +#define APLIC_MIN_SIZE 0x4000 +#define APLIC_SIZE_ALIGN(x) ROUNDUP(x, APLIC_MIN_SIZE) =20 -#define APLIC_SIZE(nr_cpus) (APLIC_MIN_SIZE + \ - APLIC_SIZE_ALIGN(APLIC_IDC_SIZE * (nr_cpu= s))) +#define APLIC_SIZE(nr_cpus) \ + (APLIC_MIN_SIZE + APLIC_SIZE_ALIGN(APLIC_IDC_SIZE * (nr_cpus))) =20 struct aplic_regs { uint32_t domaincfg; /* 0x0000 */ @@ -82,7 +138,7 @@ struct aplic_regs { uint8_t _reserved11[4088]; /* 0x2008 */ =20 uint32_t genmsi; /* 0x3000 */ - uint32_t target[1023]; /* 0x3008 */ + uint32_t target[1023]; /* 0x3004 */ }; =20 #endif /* ASM_RISCV_APLIC_H */ --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844128; cv=none; d=zohomail.com; s=zohoarc; b=Gzp288WQ4BMvs/Q47e6PrqohtSSwTIbk1aCPPuqAS5jGmP1m+p82aII5FHl4+Agkz0gB10LRJ1seUpNTAKLTYGhOiEL7vSs/gGDWqNVZ9Usl03oP8xZGlJJDN47gBA7Fk/aYT7WkxisHrABt1iv6x1rN6SeLM5n/Dy+pHCVvmiI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844128; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=mh6VNmg6fph8ZjJKqYXDVKtLdFlz1wuNoXDYt9j8GKQ=; b=Nc2ZAL0lVuih0liBr942oTJb1VzNcKBl9/TzfazqspvgjltMQggkZVlkwvvSJZ+H53aW7yYjFjn1ut0D3CUkkUnabDCd1wgSxIrcwu76umu3sDS8aWujpdtoga6R5Xfyz6rTA48HkJ3XlR/v7N+RszrjuodCL2x+608HehPj7sI= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844128457750.6363501090344; Thu, 27 Aug 2026 08:22:08 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400927.1636611 (Exim 4.92) (envelope-from ) id 1wzbvN-00080V-7L; Thu, 27 Aug 2026 15:21:53 +0000 Received: by outflank-mailman (output) from mailman id 1400927.1636611; Thu, 27 Aug 2026 15:21:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbvN-00080G-1c; Thu, 27 Aug 2026 15:21:53 +0000 Received: by outflank-mailman (input) for mailman id 1400927; Thu, 27 Aug 2026 15:21:51 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvL-0007he-2e for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:21:51 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvK-009ksf-Fq for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:21:50 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9055fd-2eae-0a2a0a5409dd-0a2a45029cdc-22 for ; Thu, 27 Aug 2026 17:21:50 +0200 Received: from [209.85.128.41] (helo=mail-wm1-f41.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a90560e-6ca4-0a2a45020019-d1558029b852-3 for ; Thu, 27 Aug 2026 17:21:50 +0200 Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-496bb7cdf51so11598645e9.2 for ; Thu, 27 Aug 2026 08:21:50 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.21.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:21:49 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844110; x=1788448910; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=mh6VNmg6fph8ZjJKqYXDVKtLdFlz1wuNoXDYt9j8GKQ=; b=DnpVX3P76wt2iOMJbJSErFsdBM2y1dKvFPY8ScFla8646j5BkD4qNO3rPXVx9u3Lze Z2WX53S848g1NTg03NH9+ai12wChpmTzaRuVDgRWXngJ7XIsw3pBU83sp0R68uwLZqOy 0QlfG8TOCU+vJ3Mcp/iHU+AE6cS4zl+MOkyb03L5Q5CYUClM92TyXRs/28TJIZxDg3nm TO8yD8MnoolPJTsPNasWL0uiWc9bTtRgnf0JgzsZ2OzHLUSO0VohkcByVu8Hx02wqw9B oUXLEDCBojWDvpCve4awpYZ9ycGMTUCB4XOd8dQ99NMi7hJ4vTZ8PWjaDIoRyoCqvsQ0 lBhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844110; x=1788448910; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=mh6VNmg6fph8ZjJKqYXDVKtLdFlz1wuNoXDYt9j8GKQ=; b=Wc6KMv0jfW8N8W2f8a8/NTawh8w9xunDjW4TMA3n4AMryMaOquxBPb6VHyk01IFaKv VmNj+HCMyoNIiSIfrZrgY5MIHF7igpTjeMbDglfRP5IqVTKqRGtIJUDojxh2tFZogiUo 4uOQL6UCTrsOKInJTc6tfiVld/YtGH8s5YT/ZPZFqbozHR+FSe97jGFGrmVhEqL07tfD qUtUQlW91PmJAh8jixCSG+OLjgbOIZEpVBFzU8q1U22KOcvfNJZe+Gbu8E3TBH5AQr6A jck108EG4D5cXC/aWfUC8WaV6Mx+K/6klhgL4q+LAtzjdfO7mgydEAask+sxDzuWBcUD 7HbA== X-Gm-Message-State: AFuF++kiGl3+mA0/PPAJvpHsauzos2+jrG8wKeT1Dg0Y++hQx6aGIsFc C5IKQBW4Scc6w3uZc6MFpDXsPDg9h953SHRdxkgLTqc0oAvumb4TPoOq6UMsIA== X-Gm-Gg: AR+sD11Dpb3YXtcLN0tC6TzWlc/E1GIIlpkhH9KRC7TD+Mwh8V3Kyr96ovL42btzWtn Bi+cHjzrlRGGrbHZHNhX/q1Am5Pu10uqU3YTaGls6hUsq40LRgRr5cCLctg6x9Eh+yWs/b/suNU rtBtcA+IYQvnaTlHthHLXwN3hmQEqwaDkmNHmaCfXhk4tsvMhApv34gcg/yDqiTx5DQe2mD2YwR 2N03IiM+3l5G5FGx2OyWHiZtSFrrmA8CAZ7sNic+4Dc+qfg0qTi3E7+m15LQ56Ul6QsWftPB8MJ bWSYY7JHzY4eOzlYCUEFWDH/8QtvCRBGHCiesPjvVIcpDqdEnq6tiHlIAu7BspEqVVrkSkvPxu0 lHu9SJ9mY7MCds9as1xHwitHj025XKWOqb6duWmTr5kke6jDy6eyvFUuhJxScp/mghFB/AdV1cB eXuL22VG/aLUmDF9vZ4KoTHWu+STsG16/NfWuwmoxcjDB7cM+0iqpdc5VLWuRZtzR5TmxK4+EJ4 5cAGqxP2WdvwYYj89TDbM9aPW18WOEptlsoVdGVfi8= X-Received: by 2002:a05:600c:c87:b0:499:d22a:8973 with SMTP id 5b1f17b1804b1-499dc6f47ccmr154953335e9.1.1787844109718; Thu, 27 Aug 2026 08:21:49 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 08/39] xen/riscv: introduce device-agnostic MMIO emulation dispatch Date: Thu, 27 Aug 2026 17:20:52 +0200 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-720697/1787844110-666B72AC-5A122C66/10/73395122804 X-purgate-type: spam X-purgate-size: 11906 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844130214158501 Content-Type: text/plain; charset="utf-8" RISC-V guests can expose several virtual interrupt controllers at distinct GPA ranges: vPLIC (hasn't been introduced yet) for legacy machines, vAPLIC and vIMSIC for AIA-compliant ones (are being introduced in the follow up patches). Routing MMIO faults via a per-device is_access() check in the trap handler would couple it to every device it must serve, requiring a new conditional branch in the fault path each time a new emulated device is added. Introduce a per-domain MMIO handler registration table, modeled after the equivalent ARM framework, so that virtual devices self-register their GPA ranges and read/write callbacks at domain creation time. The MMIO fault path delegates to a single try_handle_mmio() entry point and remains agnostic of which device owns a particular address. A subsequent patch wires this into the MMIO fault path in traps.c. Signed-off-by: Oleksii Kurochko --- Changes in v2: - Drop copyright from mmio.c as it will go stale anyway as code moves around. - Drop the max_count parameter of domain_io_init() (MAX_IO_HANDLER is a global boundary) and embed the handler array directly in struct vmmio as struct mmio_handler handlers[MAX_IO_HANDLER]. This removes the xvzalloc_array() allocation, the max_num_entries field and domain_io_free() altogether; domain_io_init() consequently cannot fail any longer and now returns void. Note this goes slightly beyond the suggested variant in that max_num_entries is dropped as well, since ARRAY_SIZE(vmmio->handlers) serves the same purpose. - Drop the separate register_t argument of mmio_read_t/mmio_write_t; handlers now produce and consume the value through info->data. handle_read()/handle_write() are gone as a result, with try_handle_mmio() invoking ops->read()/ops->write() directly. - Turn mmio_read_t/mmio_write_t into function types rather than pointer-to-function types, so that pointer-ness is visible at the use sites in struct mmio_handler_ops. Constify the mmio_info_t * of the write callback, which has no reason to modify it any more. - register_mmio_handler() returns int instead of BUG_ON()ing on a full table: -ENOSPC now lets the caller fail domain creation. It also validates its inputs, rejecting a NULL ops (or one with a missing read/write callback) as well as zero-sized and address-wrapping regions with -EINVAL. - Guarantee the non-overlap property that cmp_mmio_handler() relies on: register_mmio_handler() checks the new region against both neighbours of its insertion slot and returns -EEXIST on overlap. - Replace the sort() call per registration with an insertion into the already sorted array: locate the slot and memmove() the tail up by one. sort(), swap_mmio_handler() and are gone. - Extend cmp_mmio_handler()'s comment to state that it is a bsearch() comparator and to explain the key/elem asymmetry; document why the neighbours' addr + size cannot overflow. - Fix over-long lines and a mis-indented label. --- --- xen/arch/riscv/Makefile | 1 + xen/arch/riscv/domain.c | 3 + xen/arch/riscv/include/asm/domain.h | 3 + xen/arch/riscv/include/asm/mmio.h | 63 ++++++++++ xen/arch/riscv/mmio.c | 176 ++++++++++++++++++++++++++++ 5 files changed, 246 insertions(+) create mode 100644 xen/arch/riscv/include/asm/mmio.h create mode 100644 xen/arch/riscv/mmio.c diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile index 3b948c11dd61..ce6410a299a4 100644 --- a/xen/arch/riscv/Makefile +++ b/xen/arch/riscv/Makefile @@ -14,6 +14,7 @@ obj-y +=3D intc.o obj-y +=3D irq.o obj-y +=3D kernel.init.o obj-y +=3D mm.o +obj-y +=3D mmio.o obj-y +=3D p2m.o obj-y +=3D paging.o obj-y +=3D pt.o diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index 57c37cb2dfc2..ec327a5e8a23 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -12,6 +12,7 @@ #include #include #include +#include #include #include =20 @@ -316,6 +317,8 @@ int arch_domain_create(struct domain *d, if ( (rc =3D p2m_init(d, config)) !=3D 0) goto fail; =20 + domain_io_init(d); + if ( (rc =3D domain_vintc_init(d)) ) goto fail; =20 diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/a= sm/domain.h index e035b33ddfdc..15e8fa19685e 100644 --- a/xen/arch/riscv/include/asm/domain.h +++ b/xen/arch/riscv/include/asm/domain.h @@ -9,6 +9,7 @@ =20 #include #include +#include #include #include =20 @@ -101,6 +102,8 @@ struct arch_domain { const unsigned long *isa; =20 struct vintc *vintc; + + struct vmmio vmmio; }; =20 #include diff --git a/xen/arch/riscv/include/asm/mmio.h b/xen/arch/riscv/include/asm= /mmio.h new file mode 100644 index 000000000000..582969e5351b --- /dev/null +++ b/xen/arch/riscv/include/asm/mmio.h @@ -0,0 +1,63 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ +#ifndef RISCV_MMIO_H +#define RISCV_MMIO_H + +#include +#include + +struct domain; +struct vcpu; + +#define MAX_IO_HANDLER 16 + +typedef struct { + paddr_t gpa; + unsigned int len; /* access width in bytes (1, 2, 4, 8) */ + bool is_write; + /* store: value to write; load: value read (set by handler) */ + register_t data; +} mmio_info_t; + +enum io_state +{ + IO_ABORT, /* The IO was handled and led to an abort. */ + IO_HANDLED, /* The IO was successfully handled. */ + IO_UNHANDLED, /* No handler found for the IO. */ +}; + +typedef enum io_state (mmio_read_t)(struct vcpu *v, mmio_info_t *info); +typedef enum io_state (mmio_write_t)(struct vcpu *v, const mmio_info_t *in= fo); + +struct mmio_handler_ops { + mmio_read_t *read; + mmio_write_t *write; +}; + +struct mmio_handler { + paddr_t addr; + paddr_t size; + const struct mmio_handler_ops *ops; +}; + +struct vmmio { + unsigned int num_entries; + rwlock_t lock; + struct mmio_handler handlers[MAX_IO_HANDLER]; +}; + +int do_mmio(mmio_info_t *info, paddr_t fault_addr, unsigned int len); +int register_mmio_handler(struct domain *d, + const struct mmio_handler_ops *ops, + paddr_t addr, paddr_t size); +void domain_io_init(struct domain *d); + +#endif /* RISCV_MMIO_H */ + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ diff --git a/xen/arch/riscv/mmio.c b/xen/arch/riscv/mmio.c new file mode 100644 index 000000000000..d241ab5ea13d --- /dev/null +++ b/xen/arch/riscv/mmio.c @@ -0,0 +1,176 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ + +#include +#include +#include +#include +#include + +#include +#include + +/* + * bsearch() comparator: @key holds the address to look up in its addr fie= ld, + * @elem is an entry of vmmio->handlers. Relies on the regions not + * overlapping, which register_mmio_handler() enforces. + */ +static int cmp_mmio_handler(const void *key, const void *elem) +{ + const struct mmio_handler *handler0 =3D key; + const struct mmio_handler *handler1 =3D elem; + + if ( handler0->addr < handler1->addr ) + return -1; + + if ( handler0->addr >=3D (handler1->addr + handler1->size) ) + return 1; + + return 0; +} + +/* + * Return a copy of the matching handler rather than a pointer into + * vmmio->handlers: a concurrent register_mmio_handler() shifts entries + * up to keep the array sorted, so an escaped pointer could refer to a + * different (or torn) entry once the lock is dropped. The copy stays + * valid as the ops structures are never freed. + */ +static bool find_mmio_handler(struct domain *d, paddr_t gpa, + struct mmio_handler *out) +{ + struct vmmio *vmmio =3D &d->arch.vmmio; + struct mmio_handler key =3D { .addr =3D gpa }; + const struct mmio_handler *handler; + + read_lock(&vmmio->lock); + handler =3D bsearch(&key, vmmio->handlers, vmmio->num_entries, + sizeof(*handler), cmp_mmio_handler); + if ( handler ) + *out =3D *handler; + read_unlock(&vmmio->lock); + + return handler !=3D NULL; +} + +static enum io_state try_handle_mmio(mmio_info_t *info) +{ + struct vcpu *v =3D current; + struct mmio_handler handler =3D {}; + + if ( !find_mmio_handler(v->domain, info->gpa, &handler) ) + return IO_UNHANDLED; + + if ( info->is_write ) + return handler.ops->write(v, info); + else + return handler.ops->read(v, info); +} + +/* + * Check alignment and dispatch a decoded MMIO access to a registered + * handler. On success (0), info->data holds the read value for loads. + * + * There is no "retry" outcome to handle: find_mmio_handler() returns a + * copy of the matching handler taken under vmmio->lock and the ops + * structures are never freed, so the lookup result cannot go stale + * between finding the handler and invoking it. + */ +int do_mmio(mmio_info_t *info, paddr_t fault_addr, unsigned int len) +{ + /* Fault address should be aligned to length of MMIO */ + if ( fault_addr & (len - 1) ) + return -EIO; + + info->gpa =3D fault_addr; + info->len =3D len; + + switch ( try_handle_mmio(info) ) + { + case IO_HANDLED: + return 0; + + case IO_ABORT: + return -EIO; + + default: + return -EOPNOTSUPP; + } +} + +int register_mmio_handler(struct domain *d, + const struct mmio_handler_ops *ops, + paddr_t addr, paddr_t size) +{ + struct vmmio *vmmio =3D &d->arch.vmmio; + struct mmio_handler *handlers =3D vmmio->handlers; + paddr_t end =3D addr + size; + unsigned int i; + int rc =3D 0; + bool overlap; + + if ( !ops || !ops->read || !ops->write || !size || end < addr ) + return -EINVAL; + + write_lock(&vmmio->lock); + + if ( vmmio->num_entries >=3D ARRAY_SIZE(vmmio->handlers) ) + { + rc =3D -ENOSPC; + goto out; + } + + /* + * The array is kept sorted by base address, so rather than appending = and + * re-sorting, find the slot the new region belongs to and shift the t= ail + * up by one. + */ + for ( i =3D vmmio->num_entries; + i > 0 && handlers[i - 1].addr > addr; + i-- ) + /* Nothing */; + + /* + * Regions are required not to overlap; check both neighbours. Their + * addr + size cannot overflow, as such regions are rejected above when + * they get registered. + */ + overlap =3D (i > 0 && handlers[i - 1].addr + handlers[i - 1].size > ad= dr) || + (i < vmmio->num_entries && end > handlers[i].addr); + + if ( overlap ) + { + rc =3D -EEXIST; + goto out; + } + + memmove(&handlers[i + 1], &handlers[i], + (vmmio->num_entries - i) * sizeof(*handlers)); + + handlers[i] =3D (struct mmio_handler){ + .addr =3D addr, + .size =3D size, + .ops =3D ops, + }; + + vmmio->num_entries++; + + out: + write_unlock(&vmmio->lock); + + return rc; +} + +void domain_io_init(struct domain *d) +{ + rwlock_init(&d->arch.vmmio.lock); + d->arch.vmmio.num_entries =3D 0; +} + +/* + * Local variables: + * mode: C + * c-file-style: "BSD" + * c-basic-offset: 4 + * indent-tabs-mode: nil + * End: + */ --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844138; cv=none; d=zohomail.com; s=zohoarc; b=P+/acI+4mTK6DpJQhonFYREfI+vxtfs33yxuMPuNRo9HXPnuJgDly1o4t5gkVqa/EPVHcCkXCMalRgeD1CvvRR7OZq2SI0ksmcLR2o7PMWvHBo/3tOf2TNqi2uds85SdJI3Z4rIIG4wSdkGdydsr76VeVTywqwGQneAkDa9Gq7c= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844138; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=wl9JDmFXe2GvW88zrD2RV31XZyZ+r6BwzzFfNH1Lx2E=; b=hR+H/7b+IZxdfzcBJuqiS+a8pZHt+OhKwQkJqcGD2mqJyyCQ6M/jK9QBemWiv8+s6ULajkV43hTJuL81j45vgZbfRtWAij+xKv0wpafzM/TCBfiudSv1m+pKX1DqmGaVYOl5C/tNF8eenkOmm6b5wW9btVnCLeop/OgqnynPobk= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844138497678.2298864915791; Thu, 27 Aug 2026 08:22:18 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400932.1636629 (Exim 4.92) (envelope-from ) id 1wzbvT-0000Lf-8h; Thu, 27 Aug 2026 15:21:59 +0000 Received: by outflank-mailman (output) from mailman id 1400932.1636629; Thu, 27 Aug 2026 15:21:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbvT-0000LP-1l; Thu, 27 Aug 2026 15:21:59 +0000 Received: by outflank-mailman (input) for mailman id 1400932; Thu, 27 Aug 2026 15:21:57 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvR-0008Te-0c for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:21:57 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvQ-009ktn-Ce for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:21:56 +0200 Received: from [10.42.69.6] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a905605-e002-0a2a0a5209dd-0a2a4506aa28-24 for ; Thu, 27 Aug 2026 17:21:56 +0200 Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com) by tlsNG-16d1c6.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a905611-195a-0a2a45060019-d1558036d9cd-3 for ; Thu, 27 Aug 2026 17:21:53 +0200 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-499d1ab3f9dso9565155e9.3 for ; Thu, 27 Aug 2026 08:21:53 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.21.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:21:50 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844113; x=1788448913; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=wl9JDmFXe2GvW88zrD2RV31XZyZ+r6BwzzFfNH1Lx2E=; b=AJxKSmdcMEjF6PcSQzIE+c5zAohR/jYMzTNgYf9VXWnBNsQqk0NhkM2l++5txIcFpz 0kT3YPRABmEYTd8xHjXqXSIfFuPqPv8YufkFiykx25RqUQWKV8ljrxfSDddd9Bhe6du6 /B8SYhoB4gUx7Fv3i1q44xyv/IlXuw8PnLCDTPw0nzEdlCwpCb7TbJPn2p+/ZxQLuUt7 dtl7rxTi9Usl1aBqSqj11d6/IQRI85bTFdHy/4Lx32BE4QQ3EpUY7h1hBERTDxnOEDhw yyxP//iPgIs8jdzK7SU4MOBZJZgv9PbPwMuGDyldGVy+p49UrFde7VyWfQrIjsGjO1F+ GkXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844113; x=1788448913; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=wl9JDmFXe2GvW88zrD2RV31XZyZ+r6BwzzFfNH1Lx2E=; b=hALeyDfvvbUEFNMhORFFYwL0A2cRXzlO3KYLXG9I3l3DjqCV26TCDXR0FC8T49ArFS HjvGgiDk7lUGlGnwvrCTmr+0BATHZiSCIczhIZjhQvqe639bGsrsUwaDMCSH2aQMcl/6 ALUJVJg8dn2/WKHLchlzSir4hb21IrLPsEC9Lko0vCT5Ri6wItcThmHbIqB3TcKddW2w XOCVa4gloFa4TgEQV83vebZTQ5ufLNZ4BIKYRPmC/jsLgw2VKH3AUiXQ+7EnPb4LPTKV 3EtCKvJH6AfjA7+YNKI5VstVGPaR64ZM/5++3NBx3hhCekye7rEdHDx9LeOKea6u/qc2 EuTA== X-Gm-Message-State: AFuF++lwVeP0u7cy30gS77WUGbIjvQTJxXXSqdRBdJf0Y3DuXrkjYg/o eACdGkEIL1GNh7AONO1NR9FlIXqVwG1aktND6KGrDy/wkOXkdaAqkDN/Hc5ufg== X-Gm-Gg: AR+sD13NN2+B11xIkBqpocoFCYNPMSJim7wOiEUb7qJXfdN05e0HXwH2b7FUtGcvN9e bYoGyT3qrXan7/wxLa173ZqZX6rQILWp8uMHV+2XFmfMQQrcHXzL/eB1PmG6hJsuPEQBAdxJRwr 4eCHpM+5z7K9GUOzc8Et1rj69TZDQOL4mz5AojHiVKckwbU52HkG8Rj3ykBHtzXkiztb9iJpP4g ZPTgDJl/a5z6s/1SVIfbE2wzkoAtV7w/GNMtzPbqDoSGPJswqe4Wkdj09/Q1rqHfXVELVZ5a9QV Lx01HiteXJ7OH5P4zY1aO8DJ//rGMuIlBGbrbh2sq5bGP0z4b0WEZU/c/ei33sKKM+2ALBO9n7u w9+sbliFIUx7wArp9ySbyUUwVB7i4E3oZkPb1W5ad7DspFy3w0hJ3j5/X3hdlQnh+nXShvsH5XX UcgcYVfM7YMCjv5Z516vTJC1f2bd1TyYbpbQcqYMYumBP/7i4Jw92jwCyW0ugS9s5ksJoTP1CT2 toQM2GsfDAQjrAmJ5+t36OPLOsRT0cq X-Received: by 2002:a05:600c:3155:b0:499:4892:d022 with SMTP id 5b1f17b1804b1-499dc6feffcmr156361545e9.8.1787844112313; Thu, 27 Aug 2026 08:21:52 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 09/39] xen/riscv: implement virtual APLIC MMIO emulation Date: Thu, 27 Aug 2026 17:20:53 +0200 Message-ID: <4413e157dfe67167f651df1ea92ab61ca4182723.1787838835.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-16d1c6/1787844113-F460277B-28EEC48C/10/73395122804 X-purgate-type: spam X-purgate-size: 26121 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844140301158500 Content-Type: text/plain; charset="utf-8" Guests running under Xen program interrupt routing by writing to APLIC MMIO registers. Xen must intercept these accesses to enforce interrupt isolation between domains and to translate guest routing intent into the underlying physical MSI topology. Writes are gated by the domain's authorised interrupt bitmap so that a guest cannot affect interrupts it does not own. TARGET register writes additionally require translation of the hart and IMSIC guest-file indices from virtual to physical, as the APLIC uses these fields directly to compute the MSI delivery address. Delegation (APLIC_SOURCECFG_D) is not yet supported. Co-developed-by: Romain Caritey Signed-off-by: Oleksii Kurochko --- Changes in v2: - Shadow the guest-written target registers in a per-domain array and serve reads of APLIC_TARGET_* from it: the hardware register holds the value produced by aplic_msi_target_gen() (physical hart field, VS-file id), so reading it back would expose the host layout and return something the guest never wrote. A non-zero guest index is dropped with a one-time warning instead of being echoed back. - aplic_hart_field(): take a CPU id instead of a hartid and derive both the group and the hart index from msi->base_addr + msi->offset - the hart index bits are a part of that offset, so the hartid can't be used as the hart index. Add APLIC_xMSICFGADDR_PPN_LHX_{MASK,SHIFT} for that. - Document the IMSIC MSI target address layout and the APLIC hart index packing above aplic_hart_field(), and correct the corresponding diagram in asm/imsic.h. - Drop the mask parameter of aplic_hw_read_reg() and apply the authorization mask in vaplic_emulate_load() instead. - vaplic_emulate_{load,store}(): return bool instead of int, rename v/d to curr/currd and add ASSERT(curr =3D=3D current). - Use domain_vcpu() instead of open-coded d->vcpu[] indexing when resolving the target hart index. - s/APLIC_REG_OFFSET_MASK/APLIC_CTRL_REGION_OFFSET_MASK/. - Update store emulation handling for target register to be able to deal with target format in both cases (MSI and Direct). - Update store emulation handling of domaincfg. There is no need to force DM/IE mode here (it will be forced/checked on Xen irq handler side). - Rename APLIC_DEFAULT_PRIORITY and move to aplic.h as default prioity value is used in vaplic code too now. --- --- xen/arch/riscv/aplic-priv.h | 3 + xen/arch/riscv/aplic.c | 128 +++++++++- xen/arch/riscv/include/asm/aplic.h | 34 +++ xen/arch/riscv/include/asm/imsic.h | 13 ++ xen/arch/riscv/include/asm/vaplic.h | 5 + xen/arch/riscv/vaplic.c | 350 +++++++++++++++++++++++++++- 6 files changed, 528 insertions(+), 5 deletions(-) diff --git a/xen/arch/riscv/aplic-priv.h b/xen/arch/riscv/aplic-priv.h index 35100d3a64fe..b3a1f79c5b76 100644 --- a/xen/arch/riscv/aplic-priv.h +++ b/xen/arch/riscv/aplic-priv.h @@ -47,4 +47,7 @@ struct aplic_priv { */ extern unsigned int guest_aplic_num_sources; =20 +uint32_t aplic_msi_target_gen(const struct vcpu *target_vcpu, + uint32_t base_val); + #endif /* ASM_RISCV_APLIC_PRIV_H */ diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c index 3681f0669efb..66ba4986a9ff 100644 --- a/xen/arch/riscv/aplic.c +++ b/xen/arch/riscv/aplic.c @@ -16,6 +16,7 @@ #include #include #include +#include #include #include #include @@ -28,8 +29,6 @@ #include #include =20 -#define APLIC_DEFAULT_PRIORITY 1 - static struct aplic_priv aplic =3D { .lock =3D SPIN_LOCK_UNLOCKED, }; @@ -38,6 +37,127 @@ static struct intc_info __ro_after_init aplic_info =3D { .hw_variant =3D INTC_APLIC, }; =20 +/* + * The arrangement of IMSIC interrupt files in MMIO space follows a topolo= gy + * defined by the RISC-V AIA specification. An IMSIC group is a set of + * interrupt files (e.g., in a cluster or socket) co-located in memory. + * + * The physical address of an outgoing MSI is calculated by bitwise ORing a + * Base Physical Page Number (Base PPN) with the Group Index (g), the Hart + * Index (h) and, for a supervisor-level interrupt domain, the Guest Index: + * + * ( Base PPN | (g << (HHXS + 12)) | (h << LHXS) | guest ) << 12 + * + * where Base PPN, HHXS, LHXS, HHXW and LHXW come from the {m,s}msiaddrcfg= [h] + * registers of the interrupt domain that sends the MSI: + * + * XLEN-1 HHXS+24 LHXS+12 12 0 + * | | | | | + * ------------------------------------------------------------ + * |xxxx| g |xxxxxxxx| h |xxxx|Guest Index| 0 | + * ------------------------------------------------------------ + * + * - g: group number. + * - h: hart number relative to the group. + * - xxxx: remaining Base PPN bits; each gap may be zero-width. + * - Guest Index: selects one of the 4 KiB pages right above the hart's own + * supervisor-level file, i.e. it starts at bit 12; LHXS must therefore = be + * at least as large as the number of guest index bits. + * - Bits 11:0: always zero because IMSIC files are 4 KiB page-aligned. + * + * For wired interrupts in MSI delivery mode (domaincfg.DM =3D 1) the APLIC + * builds that address itself from the "Hart Index" field (bits 31:18) of = the + * corresponding target[i] register. That field holds a hart index *number= *, + * in which both indices are packed adjacently: + * + * 13 lhxw+hhxw lhxw 0 + * | | | | + * ------------------------------------ + * | 0 |Group Index|Hart Index| + * ------------------------------------ + * + * - lhxw (Low Hart Index Width): the number of bits used for the hart num= ber + * within a group. + * - hhxw (High Hart Index Width): the number of bits used for the group + * number; the remaining bits of the field must be zero. + * + * The Guest Index isn't a part of it: for a supervisor-level interrupt do= main + * it has its own field (bits 17:12) in target[i]. + * + * Because there are "xxxx" gaps (Base PPN bits) between the indices in the + * physical address (depending on HHXS and LHXS), software must extract the + * group and hart components separately and pack them into the APLIC-defin= ed + * Hart Index format to ensure correct MSI targeting. + */ +static unsigned long aplic_hart_field(unsigned int cpu) +{ + const struct imsic_config *imsic =3D imsic_get_config(); + const struct imsic_msi *msi =3D &imsic->msi[cpu]; + /* Low Hart Index Shift */ + unsigned int lhxs =3D imsic->guest_index_bits; + /* Low Hart Index Width */ + unsigned int lhxw =3D imsic->hart_index_bits; + /* High Hart Index Width */ + unsigned int hhxw =3D imsic->group_index_bits; + /* High Hart Index Shift */ + unsigned int hhxs =3D + imsic->group_index_shift - APLIC_xMSICFGADDR_PPN_SHIFT * 2; + /* + * msi->base_addr is the base of the MMIO regset this CPU's interrupt + * files live in, and one regset can cover several harts; msi->offset + * selects this CPU's block inside it. The hart index bits are part of + * that offset, so both indexes have to be derived from the full addre= ss. + */ + paddr_t target_addr =3D msi->base_addr + msi->offset; + unsigned long tppn =3D target_addr >> APLIC_xMSICFGADDR_PPN_SHIFT; + unsigned long g =3D + (tppn >> APLIC_xMSICFGADDR_PPN_HHX_SHIFT(hhxs)) & + APLIC_xMSICFGADDR_PPN_HHX_MASK(hhxw); + unsigned long h =3D + (tppn >> APLIC_xMSICFGADDR_PPN_LHX_SHIFT(lhxs)) & + APLIC_xMSICFGADDR_PPN_LHX_MASK(lhxw); + + return (g << lhxw) | h; +} + +uint32_t aplic_msi_target_gen(const struct vcpu *target_vcpu, + uint32_t base_val) +{ + unsigned int guest_id =3D vcpu_guest_file_id(target_vcpu); + unsigned long hart_field =3D aplic_hart_field(target_vcpu->processor); + + base_val &=3D APLIC_TARGET_EIID; + base_val |=3D MASK_INSR(guest_id, APLIC_TARGET_GUEST_IDX); + base_val |=3D MASK_INSR(hart_field, APLIC_TARGET_HART_IDX); + + return base_val; +} + +uint32_t aplic_hw_read_reg(unsigned int offset) +{ + unsigned long flags; + uint32_t val; + + ASSERT((offset < aplic.size) && IS_ALIGNED(offset, sizeof(uint32_t))); + + spin_lock_irqsave(&aplic.lock, flags); + val =3D readl((volatile void __iomem *)aplic.regs + offset); + spin_unlock_irqrestore(&aplic.lock, flags); + + return val; +} + +void aplic_hw_write_reg(unsigned int offset, uint32_t value) +{ + unsigned long flags; + + ASSERT((offset < aplic.size) && IS_ALIGNED(offset, sizeof(uint32_t))); + + spin_lock_irqsave(&aplic.lock, flags); + writel(value, (volatile void __iomem *)aplic.regs + offset); + spin_unlock_irqrestore(&aplic.lock, flags); +} + static void __init aplic_init_hw_interrupts(void) { unsigned int i; @@ -53,9 +173,9 @@ static void __init aplic_init_hw_interrupts(void) /* * Low bits of target register contains Interrupt Priority bits wh= ich * can't be zero according to AIA spec. - * Thereby they are initialized to APLIC_DEFAULT_PRIORITY. + * Thereby they are initialized to APLIC_TARGET_IPRIO_DEFAULT. */ - writel(APLIC_DEFAULT_PRIORITY, &aplic.regs->target[i]); + writel(APLIC_TARGET_IPRIO_DEFAULT, &aplic.regs->target[i]); } =20 writel(APLIC_DOMAINCFG_IE | APLIC_DOMAINCFG_DM, &aplic.regs->domaincfg= ); diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/as= m/aplic.h index a2af55d54fc0..babba386071f 100644 --- a/xen/arch/riscv/include/asm/aplic.h +++ b/xen/arch/riscv/include/asm/aplic.h @@ -39,6 +39,13 @@ #define APLIC_DOMAINCFG_IE BIT(8, U) #define APLIC_DOMAINCFG_DM BIT(2, U) #define APLIC_DOMAINCFG_BE BIT(0, U) +/* + * The bits a write may change. Everything else, including the read-only z= ero + * bit 7 and the reserved bits, has to read back as zero, and BE is WARL a= nd + * hardwired to 0 as Xen is little-endian only. + */ +#define APLIC_DOMAINCFG_WMASK (APLIC_DOMAINCFG_IE | \ + APLIC_DOMAINCFG_DM) =20 #define APLIC_SOURCECFG_BASE 0x0004 #define APLIC_SOURCECFG_LAST 0x0ffc @@ -89,6 +96,9 @@ #define APLIC_TARGET_GUEST_IDX GENMASK(17, 12) /* Bit 11 is reserved and reads as zero */ #define APLIC_TARGET_EIID GENMASK(10, 0) +/* If target is in DM mode */ +#define APLIC_TARGET_IPRIO GENMASK(7, 0) +#define APLIC_TARGET_IPRIO_DEFAULT 1U =20 #define APLIC_IDC_SIZE 32 =20 @@ -98,6 +108,27 @@ #define APLIC_SIZE(nr_cpus) \ (APLIC_MIN_SIZE + APLIC_SIZE_ALIGN(APLIC_IDC_SIZE * (nr_cpus))) =20 +/* + * Using setip is fine here, as all SET* and CLR* register groups consist = of 32 + * registers and therefore have identical sizes. + * + * Lowest 2 bits are always zero for SET* and CLR* registers. + */ +#define APLIC_SETCLR_OFFSET_MASK \ + (sizeof_field(struct aplic_regs, setip) - sizeof(uint32_t)) + +#define APLIC_xMSICFGADDR_PPN_SHIFT IMSIC_MMIO_PAGE_SHIFT + +#define APLIC_xMSICFGADDR_PPN_HHX_MASK(hhxw) \ + (BIT(hhxw, UL) - 1) +#define APLIC_xMSICFGADDR_PPN_HHX_SHIFT(hhxs) \ + ((hhxs) + APLIC_xMSICFGADDR_PPN_SHIFT) + +#define APLIC_xMSICFGADDR_PPN_LHX_MASK(lhxw) \ + (BIT(lhxw, UL) - 1) +#define APLIC_xMSICFGADDR_PPN_LHX_SHIFT(lhxs) \ + (lhxs) + struct aplic_regs { uint32_t domaincfg; /* 0x0000 */ uint32_t sourcecfg[1023]; /* 0x0004 */ @@ -141,4 +172,7 @@ struct aplic_regs { uint32_t target[1023]; /* 0x3004 */ }; =20 +uint32_t aplic_hw_read_reg(unsigned int offset); +void aplic_hw_write_reg(unsigned int offset, uint32_t value); + #endif /* ASM_RISCV_APLIC_H */ diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/as= m/imsic.h index 2425430ed116..93f9e44c7d2c 100644 --- a/xen/arch/riscv/include/asm/imsic.h +++ b/xen/arch/riscv/include/asm/imsic.h @@ -40,6 +40,19 @@ struct imsic_config { /* Base address */ paddr_t base_addr; =20 + /* + * MSI Target Address Scheme + * + * XLEN-1 HHXS+24 LHXS+12 12 0 + * | | | | | + * ------------------------------------------------------------ + * |xxxx| g |xxxxxxxx| h |xxxx|Guest Index| 0 | + * ------------------------------------------------------------ + * - g: group number. + * - h: hart number relative to the group. + * - xxxx: remaining Base PPN bits; each gap may be zero-width. + */ + /* Bits representing Guest index, HART index, and Group index */ unsigned int guest_index_bits; unsigned int hart_index_bits; diff --git a/xen/arch/riscv/include/asm/vaplic.h b/xen/arch/riscv/include/a= sm/vaplic.h index 96080bfbc23b..046c604915c4 100644 --- a/xen/arch/riscv/include/asm/vaplic.h +++ b/xen/arch/riscv/include/asm/vaplic.h @@ -21,11 +21,16 @@ struct domain; =20 struct vaplic_regs { uint32_t domaincfg; + + uint32_t *target; }; =20 struct vaplic { struct vintc vintc; struct vaplic_regs regs; + + paddr_t regs_start; + unsigned int regs_size; }; =20 int domain_vaplic_init(struct domain *d); diff --git a/xen/arch/riscv/vaplic.c b/xen/arch/riscv/vaplic.c index 14f6e3164a9b..8726f7203d6e 100644 --- a/xen/arch/riscv/vaplic.c +++ b/xen/arch/riscv/vaplic.c @@ -17,6 +17,7 @@ #include #include #include +#include #include =20 #include "aplic-priv.h" @@ -27,6 +28,279 @@ unsigned int __ro_after_init guest_aplic_num_sources; =20 #define FDT_VAPLIC_INT_CELLS 2 =20 +#define AUTH_IRQ_BIT(d, irqn) \ + (((irqn) < (d)->arch.vintc->nr_virqs) && \ + test_bit(irqn, (d)->arch.vintc->used_irqs)) + +/* + * Convert a byte offset (within a SETIP/CLRIP/SETIE/CLRIE register group)= to + * a 32-bit word index into the used_irqs bitmap. Each word covers 32 + * interrupt sources. For SOURCECFG and TARGET groups the same division al= so + * yields the interrupt number directly, because those arrays store one 32= -bit + * register per source. + */ +#define regoffset_to_word_idx(reg_val) ((reg_val) / sizeof(uint32_t)) + +static uint32_t vaplic_target_read(const struct domain *d, unsigned int ir= qn) +{ + const struct vaplic *vaplic =3D to_vaplic(d); + + /* target[0] doesn't exist so irqn =3D=3D 0 should be impossible */ + if ( !irqn || irqn >=3D vaplic->vintc.nr_virqs ) + return 0; + + return read_atomic(&vaplic->regs.target[irqn]); +} + +static inline uint32_t generate_auth_mask(const struct domain *currd, + unsigned int word_idx) +{ + unsigned int first_bit =3D word_idx * sizeof(uint32_t) * BITS_PER_BYTE; + + if ( word_idx >=3D DIV_ROUND_UP(currd->arch.vintc->nr_virqs, + sizeof(uint32_t) * BITS_PER_BYTE) ) + { + gdprintk(XENLOG_DEBUG, "incorrect word_idx(%u) is passed\n", word_= idx); + + return 0; + } + + return currd->arch.vintc->used_irqs[first_bit / BITS_PER_LONG] >> + (first_bit % BITS_PER_LONG); +} + +static bool vaplic_emulate_load(const struct vcpu *curr, paddr_t addr, + uint32_t *out) +{ + const struct domain *currd =3D curr->domain; + const struct vaplic *vaplic =3D to_vaplic(currd); + const unsigned int offset =3D addr & APLIC_CTRL_REGION_OFFSET_MASK; + uint32_t auth_mask; + unsigned int i; + + ASSERT(curr =3D=3D current); + + switch ( offset ) + { + case APLIC_DOMAINCFG: + *out =3D vaplic->regs.domaincfg; + + return true; + + case APLIC_SETIPNUM: + case APLIC_SETIPNUM_LE: + case APLIC_CLRIPNUM: + case APLIC_SETIENUM: + case APLIC_CLRIENUM: + case APLIC_CLRIE_BASE ... APLIC_CLRIE_LAST: + /* + * Based on the RISC-V AIA spec a read of these registers + * always returns zero + */ + *out =3D 0; + + return true; + + case APLIC_SETIP_BASE ... APLIC_SETIP_LAST: + case APLIC_CLRIP_BASE ... APLIC_CLRIP_LAST: + case APLIC_SETIE_BASE ... APLIC_SETIE_LAST: + i =3D regoffset_to_word_idx(offset & APLIC_SETCLR_OFFSET_MASK); + auth_mask =3D generate_auth_mask(currd, i); + + break; + + case APLIC_TARGET_BASE ... APLIC_TARGET_LAST: + /* + * As target registers start from 1: + * 0x3000 genmsi + * 0x3004 target[1] + * 0x3008 target[2] + * ... + * 0x3FFC target[1023] + * It is necessary to calculate an interrupt number by subtracting + * APLIC_GENMSI instead of APLIC_TARGET_BASE. + */ + i =3D regoffset_to_word_idx(offset - APLIC_GENMSI); + + *out =3D AUTH_IRQ_BIT(currd, i) ? vaplic_target_read(currd, i) : 0; + + return true; + + default: + gdprintk(XENLOG_WARNING, "Unhandled APLIC read at offset %#x\n", + offset); + + return false; + } + + *out =3D aplic_hw_read_reg(offset) & auth_mask; + + return true; +} + +static bool vaplic_emulate_store(const struct vcpu *curr, paddr_t addr, + uint32_t value) +{ + const struct domain *currd =3D curr->domain; + unsigned int offset =3D addr & APLIC_CTRL_REGION_OFFSET_MASK; + + ASSERT(curr =3D=3D current); + + switch ( offset ) + { + case APLIC_SETIP_BASE ... APLIC_SETIP_LAST: + case APLIC_CLRIP_BASE ... APLIC_CLRIP_LAST: + case APLIC_SETIE_BASE ... APLIC_SETIE_LAST: + case APLIC_CLRIE_BASE ... APLIC_CLRIE_LAST: + { + unsigned int word_idx =3D + regoffset_to_word_idx(offset & APLIC_SETCLR_OFFSET_MASK); + + value &=3D generate_auth_mask(currd, word_idx); + + break; + } + + case APLIC_SOURCECFG_BASE ... APLIC_SOURCECFG_LAST: + if ( value & APLIC_SOURCECFG_D ) + { + dprintk(XENLOG_ERR, "APLIC_SOURCECFG_D isn't supported\n"); + + goto fail; + } + + /* + * As sourcecfg register starts from 1: + * 0x0000 domaincfg + * 0x0004 sourcecfg[1] + * 0x0008 sourcecfg[2] + * ... + * 0x0FFC sourcecfg[1023] + * It is necessary to calculate an interrupt number by subtracting + * APLIC_DOMAINCFG instead of APLIC_SOURCECFG_BASE. + */ + if ( !AUTH_IRQ_BIT(currd, + regoffset_to_word_idx(offset - APLIC_DOMAINCFG)= ) ) + /* Interrupt not enabled, ignore it */ + return true; + + if ( value > APLIC_SOURCECFG_SM_LEVEL_LOW ) + { + gdprintk(XENLOG_ERR, + "value(%#x) is incorrect for sourcecfg register\n", + value); + + return true; + } + + break; + + case APLIC_TARGET_BASE ... APLIC_TARGET_LAST: + { + struct vaplic *vaplic =3D to_vaplic(currd); + struct vcpu *target_vcpu; + unsigned int guest_hart_idx =3D MASK_EXTR(value, APLIC_TARGET_HART= _IDX); + /* + * Look at vaplic_emulate_load() for explanation why APLIC_GENMSI = is + * subtracted. + */ + unsigned int srcn =3D regoffset_to_word_idx(offset - APLIC_GENMSI); + + if ( !AUTH_IRQ_BIT(currd, srcn) ) + /* Interrupt not enabled, ignore it */ + return true; + + target_vcpu =3D domain_vcpu(currd, guest_hart_idx); + + if ( !target_vcpu ) + { + dprintk(XENLOG_ERR, "Invalid vCPU id in target register\n"); + + /* Ignore such writings */ + return true; + } + + if ( vaplic->regs.domaincfg & APLIC_DOMAINCFG_DM ) + { + /* + * A non-zero guest index asks for delivery to an interrupt fi= le of + * nested guest. The vIMSIC node has no riscv,guest-index-bits + * property, so a guest is told its harts have no guest interr= upt + * files and the field is read-only zero for them. The write i= sn't + * rejected (that would throw away a valid hart index and EIID= ); + * instead the field is dropped, which is also what + * aplic_msi_target_gen() does with it when programming the h/= w. + */ + if ( MASK_EXTR(value, APLIC_TARGET_GUEST_IDX) ) + { + printk_once(XENLOG_WARNING + "%pd: vAPLIC target guest index !=3D 0 is unsu= pported\n", + currd); + + /* Ignore such writes ... */ + return true; + } + + write_atomic(&vaplic->regs.target[srcn], value); + + value =3D aplic_msi_target_gen(target_vcpu, value); + } + else + { + /* + * IPRIO is WARL and zero isn't a legal value for it, so norma= lize + * it once: the guest then reads back exactly what it gets. + */ + unsigned int iprio =3D MASK_EXTR(value, APLIC_TARGET_IPRIO) ?: + APLIC_TARGET_IPRIO_DEFAULT; + unsigned long h =3D cpuid_to_hartid(guest_hart_idx); + + value =3D MASK_INSR(guest_hart_idx, APLIC_TARGET_HART_IDX) | + MASK_INSR(iprio, APLIC_TARGET_IPRIO); + + write_atomic(&vaplic->regs.target[srcn], value); + + value =3D MASK_INSR(h, APLIC_TARGET_HART_IDX) | + MASK_INSR(iprio, APLIC_TARGET_IPRIO); + } + + break; + } + + case APLIC_SETIPNUM: + case APLIC_SETIPNUM_LE: + case APLIC_CLRIPNUM: + case APLIC_SETIENUM: + case APLIC_CLRIENUM: + if ( !value || !AUTH_IRQ_BIT(currd, value) ) + return true; + + break; + + case APLIC_DOMAINCFG: + { + struct vaplic *vaplic =3D to_vaplic(currd); + + vaplic->regs.domaincfg =3D APLIC_DOMAINCFG_RO | + (value & APLIC_DOMAINCFG_WMASK); + + return true; + } + + default: + fail: + gdprintk(XENLOG_WARNING, + "Unhandled APLIC write at offset %#x (value %#x)\n", offs= et, + value); + + return false; + } + + aplic_hw_write_reg(offset, value); + + return true; +} + static int __init cf_check vaplic_make_domu_dt_node(struct kernel_info *ki= nfo) { struct domain *d =3D kinfo->bd.d; @@ -95,6 +369,56 @@ static const struct vintc_init_ops __initconstrel init_= ops =3D { .make_domu_dt_node =3D vaplic_make_domu_dt_node, }; =20 +static enum io_state cf_check vaplic_mmio_read(struct vcpu *v, + mmio_info_t *info) +{ + uint32_t val; + + ASSERT(v =3D=3D current); + + if ( info->len !=3D sizeof(uint32_t) || + !IS_ALIGNED(info->gpa, sizeof(uint32_t)) ) + { + gdprintk(XENLOG_DEBUG, + "VAPLIC: unaligned/wrong-width read gpa=3D%"PRIpaddr" len= =3D%u\n", + info->gpa, info->len); + return IO_ABORT; + } + + if ( !vaplic_emulate_load(v, info->gpa, &val) ) + return IO_ABORT; + + /* APLIC registers are 32-bit; zero-extend to the guest register width= . */ + info->data =3D val; + + return IO_HANDLED; +} + +static enum io_state cf_check vaplic_mmio_write(struct vcpu *v, + const mmio_info_t *info) +{ + ASSERT(v =3D=3D current); + + if ( info->len !=3D sizeof(uint32_t) || + !IS_ALIGNED(info->gpa, sizeof(uint32_t)) ) + { + gdprintk(XENLOG_DEBUG, + "VAPLIC: unaligned/wrong-width write gpa=3D%"PRIpaddr" le= n=3D%u\n", + info->gpa, info->len); + return IO_ABORT; + } + + if ( !vaplic_emulate_store(v, info->gpa, info->data) ) + return IO_ABORT; + + return IO_HANDLED; +} + +static const struct mmio_handler_ops vaplic_mmio_ops =3D { + .read =3D vaplic_mmio_read, + .write =3D vaplic_mmio_write, +}; + static const struct vintc_ops vintc_ops =3D { .vcpu_init =3D vcpu_imsic_init, .vcpu_deinit =3D vcpu_imsic_deinit, @@ -103,6 +427,7 @@ static const struct vintc_ops vintc_ops =3D { int domain_vaplic_init(struct domain *d) { struct vaplic *vaplic =3D xvzalloc(struct vaplic); + int rc; =20 if ( !vaplic ) return -ENOMEM; @@ -122,7 +447,29 @@ int domain_vaplic_init(struct domain *d) */ d->arch.vintc->nr_virqs =3D guest_aplic_num_sources + 1; =20 - return 0; + /* Slot 0 is unused: APLIC source numbering starts at 1 (see used_irqs= ). */ + vaplic->regs.target =3D xvzalloc_array(uint32_t, d->arch.vintc->nr_vir= qs); + if ( !vaplic->regs.target ) + { + d->arch.vintc =3D NULL; + xvfree(vaplic); + + return -ENOMEM; + } + + vaplic->regs_start =3D GUEST_APLIC_S_BASE; + vaplic->regs_size =3D APLIC_SIZE(d->max_vcpus); + + rc =3D register_mmio_handler(d, &vaplic_mmio_ops, + vaplic->regs_start, vaplic->regs_size); + if ( rc ) + { + d->arch.vintc =3D NULL; + xvfree(vaplic->regs.target); + xvfree(vaplic); + } + + return rc; } =20 void domain_vaplic_deinit(struct domain *d) @@ -134,5 +481,6 @@ void domain_vaplic_deinit(struct domain *d) =20 vaplic =3D to_vaplic(d); d->arch.vintc =3D NULL; + xvfree(vaplic->regs.target); xvfree(vaplic); } --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844141; cv=none; d=zohomail.com; s=zohoarc; b=JQsTc7p0dNecLpm6I8V3FbhnTTPYCA0fRE4LxGYFwSqBtZ/8xpJUDoUxHAUu07CMY6B+YF7g1X6da3dozOTwX5x1UoNIeVd70VhBmM3ajDgKKC6StssNcrg7RV8aj5lcF9hbvAd1dDIAhLoGqnKGlJsBe3DcJYm9JH1tqbb7+Ic= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844141; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=/P8xZRmILVBwvtPdkB4I0aQ1y0MycS9Llx86VOjksHY=; b=AFjyoTF0WteLn5jYBWIKjAUKeGSMg9GHT+vHNiV2p4xigDysHZGzlwI+6U2j8e23FR0+r6C1Cx+KHV0yuy5/TCynODQsEYsa7PgjN4jGn7d8ra2zquiq1/NTHhy6ajS2tz/SPWmVzFNmm74NgY2Ix9X14trzM8unzlKWRidO30s= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844141091593.9401672741631; Thu, 27 Aug 2026 08:22:21 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400930.1636620 (Exim 4.92) (envelope-from ) id 1wzbvQ-0008QC-K4; Thu, 27 Aug 2026 15:21:56 +0000 Received: by outflank-mailman (output) from mailman id 1400930.1636620; Thu, 27 Aug 2026 15:21:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbvQ-0008Pv-E8; Thu, 27 Aug 2026 15:21:56 +0000 Received: by outflank-mailman (input) for mailman id 1400930; Thu, 27 Aug 2026 15:21:55 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvP-0008My-O3 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:21:55 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvP-009ksf-4Q for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:21:55 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a9055fd-2eae-0a2a0a5409dd-0a2a45029cdc-30 for ; Thu, 27 Aug 2026 17:21:55 +0200 Received: from [209.85.128.42] (helo=mail-wm1-f42.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a905612-6ca4-0a2a45020019-d155802addd0-3 for ; Thu, 27 Aug 2026 17:21:55 +0200 Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-499ac87c92bso20713995e9.1 for ; Thu, 27 Aug 2026 08:21:55 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.21.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:21:53 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844114; x=1788448914; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=/P8xZRmILVBwvtPdkB4I0aQ1y0MycS9Llx86VOjksHY=; b=FD4vFwDRDUqPDdZWTlz2kaoaO6aDNVb32rh0cNcXc/RFPyc0XY9SoAhKiX8g4GEV00 uzhFNZBjQnWhE0FShkjB1chUoiqI0EWulGlWp6sAVJ12xyyBwdConyiKTGmLERzsMSVA yMBl3N4l24f9Vk43S9ROF9qb2LYnjHyri0OUoajBOif114JO77m9zWgLMNqG9AZ9glU9 /DtAEtssEW+Ckpg/C6QPYslm0lX8IJnSZSoE+scvaWiZOjMEJHp6ZHVoq1/Y0miNTGUj UWTbbEdXwLu5d0BuIX/zWgzglTfK8c2VcnGibyReWlJYi0F+ZC6P/3p8sWYgIJVwNrBD kI7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844114; x=1788448914; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=/P8xZRmILVBwvtPdkB4I0aQ1y0MycS9Llx86VOjksHY=; b=dZbLfdc7GVM3U0lXaG8gQvjGVY66p/M0keepWnMbAQB1oheShZpQxgnIe3L1Ua1rKG n5UYc6sI+eN+IgP9jUq41eaFatt/jUth9av3vA+rG1c33mmE5dtRHPDwujnJplREdGL4 FmDhkJTFFAW1bdYt8WOl9uc2eravHyjKK/WN4F9KOE9DW0nMAYeQwpD5WZGF1dFk7DQu aCyf2wlcs9GmgrW9noAUdyPF8JLwPVMMM1xEoMSw2tWW6Ner75Pn741stsQsUEE5EPH/ KVVAlX8F+nsd348u4MJrOLBkyDahWg5Ov0F0wA31t5iboBG8+b+gKxz0gR3ccNYCk2OA YSow== X-Gm-Message-State: AFuF++myjZrdQgMCJcxjFooqi8iI8N+OO5c46LES/bi8QwnFnBkeOYGZ SLzmJLWF/S2dHdjFxNHMC8NMkioHPFjHRmkRBdgwPCA4z1BJIujXB6jmpatzEQ== X-Gm-Gg: AR+sD10S7JlFcL0jpbnSKIyZh8EQ7sNFVxaFKDHohMPBkxqDQcY+sKps9QqwiDPBjJe z4fosNQT+qLoI26SxIPZ3vxfycy+fVl4yk1sCTSU/dV49Y2pvMg9dHK/0LDzGrSDYeBHyUzGf1H oEEsEMAKqBdqmYFOLVYDjFTliZk6kjzD+zBbCb3XWr9OMsqGNvDTOLwkvXMmi6pqDNVnpXnSbDu Lknk0EkRLFVZTgv+an6SzoQ6G5W0LKfJUzfNDYGRaw19STNaQaw/enSLmzyfyFYdVdZPYuS7nJ1 TfNiCI0TUpRU2btaqR2KB5z5LWy6JajDUVgphTxw6SR+7REsoXLg2hvd7Ap4rqBBB6Fd+l7pgwi NOtyKCPANXSpSsJg7Ys5i9lB976pKrRhjV3bAsLNeyZGE/q+wTlc7U/BTKfX1dmtHUSEb/zBDv1 OUJrFJSlSPbeL+KdARwmqu2TMG4MoQzdsbVKC/qFt9Sz0Q4mDOwrHlAJQA45b8tqFqtFikgZ1ER drd79WSYBhtefbxrbEr1Ftvq1QzmqvW X-Received: by 2002:a05:600c:34c3:b0:495:4d88:e630 with SMTP id 5b1f17b1804b1-499dc720bd2mr214670815e9.10.1787844113604; Thu, 27 Aug 2026 08:21:53 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 10/39] xen/riscv: build the target hart index via aplic_hart_field() Date: Thu, 27 Aug 2026 17:20:54 +0200 Message-ID: <3c7418d64a730ec5e4b2cfd0ecfbbbc6fe0bf7d8.1787838835.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-720697/1787844115-F2CB22AC-6949A792/10/73395122804 X-purgate-type: spam X-purgate-size: 4299 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844142209158500 Content-Type: text/plain; charset="utf-8" aplic_set_irq_affinity() open-coded the packing of the group and hart indices into the target register, and got two things wrong along the way: - imsic_config.msi[] is indexed by logical CPU id, but the index was run through cpuid_to_hartid() first. On any platform where the two spaces differ this picks another CPU's interrupt file, or reads past the array; - the same hart id was then used verbatim as the low hart index, and the group index was derived from msi[].base_addr alone. The hart index bits live in msi[].offset, the base address only covers the MMIO regset, which may hold the files of several harts. Both indices have to come out of base_addr + offset. aplic_hart_field() already extracts them that way, and is what the vAPLIC target path uses, so call it here as well and insert the result with MASK_INSR(APLIC_TARGET_HART_IDX) instead of a bare shift, which keeps the value from spilling out of the 14-bit field. This also drops the last in-tree duplicate of the AIA hart index formula. So drop defintion of APLIC_TARGET_HART_IDX_SHIFT. No functional change on a single-group platform whose hart ids match their CPU ids and whose IMSIC regset holds one file per hart. Fixes: d4676a1398bc ("xen/riscv: implementation of aplic and imsic operatio= ns") Signed-off-by: Oleksii Kurochko --- Changes in v2: - New patch. --- --- xen/arch/riscv/aplic.c | 30 ++++++------------------------ xen/arch/riscv/include/asm/aplic.h | 1 - 2 files changed, 6 insertions(+), 25 deletions(-) diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c index 66ba4986a9ff..319a954f6f3c 100644 --- a/xen/arch/riscv/aplic.c +++ b/xen/arch/riscv/aplic.c @@ -325,9 +325,7 @@ static unsigned int aplic_get_cpu_from_mask(const cpuma= sk_t *cpumask) static void cf_check aplic_set_irq_affinity(struct irq_desc *desc, const c= pumask_t *mask) { unsigned int cpu; - uint64_t group_index, base_ppn; - uint32_t hhxw, lhxw, hhxs, value; - const struct imsic_config *imsic =3D aplic.imsic_cfg; + uint32_t value; =20 /* * TODO: Currently, APLIC is supported only with MSI interrupts. @@ -340,27 +338,11 @@ static void cf_check aplic_set_irq_affinity(struct ir= q_desc *desc, const cpumask =20 ASSERT(spin_is_locked(&desc->lock)); =20 - cpu =3D cpuid_to_hartid(aplic_get_cpu_from_mask(mask)); - hhxw =3D imsic->group_index_bits; - lhxw =3D imsic->hart_index_bits; - /* - * Although this variable is used only once in the calculation of - * group_index, and it might seem that hhxs could be defined as: - * hhxs =3D imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT; - * and then the addition of IMSIC_MMIO_PAGE_SHIFT could be omitted - * when calculating the group index. - * It was done intentionally this way to follow the formula from - * the AIA specification for calculating the MSI address. - */ - hhxs =3D imsic->group_index_shift - IMSIC_MMIO_PAGE_SHIFT * 2; - base_ppn =3D imsic->msi[cpu].base_addr >> IMSIC_MMIO_PAGE_SHIFT; - - /* Update hart and EEID in the target register */ - group_index =3D (base_ppn >> (hhxs + IMSIC_MMIO_PAGE_SHIFT)) & - (BIT(hhxw, UL) - 1); - value =3D desc->irq; - value |=3D cpu << APLIC_TARGET_HART_IDX_SHIFT; - value |=3D group_index << (lhxw + APLIC_TARGET_HART_IDX_SHIFT); + cpu =3D aplic_get_cpu_from_mask(mask); + + /* Update hart index and EIID in the target register */ + value =3D MASK_INSR(aplic_hart_field(cpu), APLIC_TARGET_HART_IDX) | + (desc->irq & APLIC_TARGET_EIID); =20 spin_lock(&aplic.lock); =20 diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/as= m/aplic.h index babba386071f..d629e1c83887 100644 --- a/xen/arch/riscv/include/asm/aplic.h +++ b/xen/arch/riscv/include/asm/aplic.h @@ -92,7 +92,6 @@ #define APLIC_TARGET_BASE 0x3004 #define APLIC_TARGET_LAST 0x3ffc #define APLIC_TARGET_HART_IDX GENMASK(31, 18) -#define APLIC_TARGET_HART_IDX_SHIFT 18 #define APLIC_TARGET_GUEST_IDX GENMASK(17, 12) /* Bit 11 is reserved and reads as zero */ #define APLIC_TARGET_EIID GENMASK(10, 0) --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844147; cv=none; d=zohomail.com; s=zohoarc; b=MbGwvIeJDGfrVqVib3NB2N042B09H32ZQ3T23Qt0RxwWW84aZvXu2r2mKKpK/N7KLi37dZLkB5wjOJTyPQuHDzGOIHC5Fkdfe5eUsD+BiGtywrcpcIdSD4BGmCACMxQJ32pln7gS6w3Zi9KBhRUSkbjj6dYLMHWF7ztQIzaKMYE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844147; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=+mUEQMJI16BPjjRNAZdOqq3piDAydbHYBCLE/r0NMJk=; b=d7iove9P/K72/7KfWduw6BfXbxUSUrlE1XVXh4dRXX8xxtMfVvhhjcge4eqG6ctCAqbrokutozu+fmTncHwKYGJuEOLynlff+gG/CUWptD9bpd0ZlD4lxZlgEKrqXQ08raz5+8HRz/HZsb4qf3SLmoxPd2Vbs5qN0lskyPQjzQU= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844147447967.7693476530234; Thu, 27 Aug 2026 08:22:27 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400938.1636639 (Exim 4.92) (envelope-from ) id 1wzbvV-0000jy-Tl; Thu, 27 Aug 2026 15:22:01 +0000 Received: by outflank-mailman (output) from mailman id 1400938.1636639; Thu, 27 Aug 2026 15:22:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbvV-0000jW-Me; Thu, 27 Aug 2026 15:22:01 +0000 Received: by outflank-mailman (input) for mailman id 1400938; Thu, 27 Aug 2026 15:22:00 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvU-0000XW-DJ for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:00 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvT-003Nrj-QN for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:21:59 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a905609-8faa-0a2a0a5109dd-0a2a4505b4fe-28 for ; Thu, 27 Aug 2026 17:21:59 +0200 Received: from [209.85.128.49] (helo=mail-wm1-f49.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a905617-4cb1-0a2a45050019-d1558031d407-3 for ; Thu, 27 Aug 2026 17:21:59 +0200 Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-49954b88fffso19307055e9.0 for ; Thu, 27 Aug 2026 08:21:59 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.21.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:21:54 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844119; x=1788448919; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=+mUEQMJI16BPjjRNAZdOqq3piDAydbHYBCLE/r0NMJk=; b=iiWPgwPYm4Qpky+c0ockvP8SnR12lzPdvYuQpUrbDs2Alyb4jrdAojslb8yNSkb89q iJ/GpfXvDobiG86Q3MZ3jipDIx3NvlpJc5vDN2hNhc6H2Fu015Y+jzsbaxZzr/YVLYZ0 O6AN2T1I/ENDvTwMT06NHMEHFlKtjBdXysJ9OiorJPkl9A9ab2HTwTv4PswlfPYQ8iCK ttVx2ar3YKKH2n14AOGCL4vWD7lBzviOqZ1n/MhbXeKWruYMwCkmknbPLBCO4e6Z/G9n AYUz80mkN96tyjcPm/orZ+y6H9G7LHZ6sNtBulBLCbyqlpGSxqwwY8WpTFZImQy4XuIA LnsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844119; x=1788448919; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=+mUEQMJI16BPjjRNAZdOqq3piDAydbHYBCLE/r0NMJk=; b=FOeI0GssIN8pIpCp8eezL+Hqm6Er/5zAhoG1ULtXxDzmoinNu82PuPMNAB3jCA5MZ6 J1qO38X0+EeDzdPMbfEPG1c0pY7Fgab2ywBWbK8852lAQqIYpnedHLWNP9kf1ipPp0jd SSm5zdhEW9lIbjYpJ86FXTTYE7abUPMDP+GYpobIa9QJtLnm6QvVwCymlnxFmnka/MeT zjgBWEkg/rlkx6bYbcba+OdlIBYH4h9uJP8y8lLv0Gm5M+kiXOAvNdVyP+/HCn/RCZ3a zkLQ7H4MOsllgP6IgJhPIUW7FTtVxbsgS7WpE/22iOti3/2QUpG6joydIp7tCKfkExYO aBwg== X-Gm-Message-State: AFuF++nDmkr6mQDKKFmV9gg6uMtCEWGTCtwyCThwayfSoOKLKgN2Sbn9 lNiHhnbSZd0hhJ9J+87tVW2nBhkrSYS4+eIpdGrJlA7d+EVPvh7RrlCGmEC3qQ== X-Gm-Gg: AR+sD13tITeHnzLMrNu0zbksMjSIA6dT7RoS2fYWp/Rfr3lKxDYqSperlMTpsyczes+ hU8ch5pgB3RXc7zXkl5w4JM10/yqN6j29JpF0sKlgiyO7Jp0BMurFwoqv61YXEOYPad/qxKHsQQ Xw4Ky0cbadqPHbwhKbfl2r7NV7fDd45sJQQ0D+c53ni6NFG6wiI781ImRx91h1EiKaBlck4GOjE 2fanmKIz8aADBx37pe8NwDbPzpxWfxe1SaFDEGrUYnQGaviQwM98utr6RHIgROqcKbNOL7qMZa4 ctTYhRDR2hmSe7IBnYE0w1og22xBkBxyV9dAjfmL+xIaWtkm3CbwbVeK8oKlJk5x90eQ1GZL8Rj akV4UMNukf4fn4j5XNsBs999ubaXVXAkZ9e7Os9wI4sK7cGpTtIGwRUs3dHR5tBZz6ipAbyY3iT xPAG6KhIQ793GvHolrSAG2wfZFgqjy3tS/nL0XyDYUoDn9PJnm/9CRc8Vm066hcxUSGpx5TXvOo MiutI5XOUNh9UxooVGg8DQBqR3hk/QL X-Received: by 2002:a05:600c:8901:b0:49b:5521:785d with SMTP id 5b1f17b1804b1-49b5530be2cmr85344635e9.4.1787844119222; Thu, 27 Aug 2026 08:21:59 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 11/39] xen/riscv: add helper to check APLIC MSI mode Date: Thu, 27 Aug 2026 17:20:55 +0200 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-c201ff/1787844119-73ABF2A1-270AB87B/10/73395122804 X-purgate-type: spam X-purgate-size: 1612 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844148267158500 Content-Type: text/plain; charset="utf-8" Use convient helper instead of open-coding the things. Signed-off-by: Oleksii Kurochko --- Changes in v2: - Rename helper. - Update the commit message. --- --- xen/arch/riscv/aplic.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c index 319a954f6f3c..b4c419755ac3 100644 --- a/xen/arch/riscv/aplic.c +++ b/xen/arch/riscv/aplic.c @@ -37,6 +37,11 @@ static struct intc_info __ro_after_init aplic_info =3D { .hw_variant =3D INTC_APLIC, }; =20 +static bool aplic_msi_mode(void) +{ + return readl(&aplic.regs->domaincfg) & APLIC_DOMAINCFG_DM; +} + /* * The arrangement of IMSIC interrupt files in MMIO space follows a topolo= gy * defined by the RISC-V AIA specification. An IMSIC group is a set of @@ -250,7 +255,7 @@ static void cf_check aplic_irq_enable(struct irq_desc *= desc) * If APLIC without MSI interrupts is required in the future, * this function will need to be updated accordingly. */ - ASSERT(readl(&aplic.regs->domaincfg) & APLIC_DOMAINCFG_DM); + ASSERT(aplic_msi_mode()); =20 ASSERT(spin_is_locked(&desc->lock)); =20 @@ -281,7 +286,7 @@ static void cf_check aplic_irq_disable(struct irq_desc = *desc) * If APLIC without MSI interrupts is required in the future, * this function will need to be updated accordingly. */ - ASSERT(readl(&aplic.regs->domaincfg) & APLIC_DOMAINCFG_DM); + ASSERT(aplic_msi_mode()); =20 ASSERT(spin_is_locked(&desc->lock)); =20 --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844144; cv=none; d=zohomail.com; s=zohoarc; b=fIGaqKmwI86WYWCZPOxI26UHfuHnD5PkvZw/R3wNamfN9QSiGG3diJrXUJZPA1zjdWbH7fog3Rn5+0tFIifR3MZ8fQYjWlDuF24GTP2i+dseTZt0B7i9JKqxax9dG/kT7NBVWLLHlO1sfbB20kZHLBaEFKTUffwHtAOxR5xL0Lo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844144; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=2V2WJTxwQddlTB5GIlNmFwYUX3diFnW07Uicf4Tu70o=; b=DkePpUrhyNzyd9RhNgOIVBD/mnuoHWei1zWooCIgFKthL4m9ybRD71ORi75sjuqS50lGWVpxejPz70fUh0Yu0gmFnb2FpLr5gS/JXvQDieHdSYh7Nu3m7X1mLCpXLJTe2/oMj6UdwSxifntlcazQr6pSFjm7WoTCOYBZJZNHFpY= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844144682113.30583678963944; Thu, 27 Aug 2026 08:22:24 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400940.1636646 (Exim 4.92) (envelope-from ) id 1wzbvX-0000z1-6F; Thu, 27 Aug 2026 15:22:03 +0000 Received: by outflank-mailman (output) from mailman id 1400940.1636646; Thu, 27 Aug 2026 15:22:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbvX-0000xw-2B; Thu, 27 Aug 2026 15:22:03 +0000 Received: by outflank-mailman (input) for mailman id 1400940; Thu, 27 Aug 2026 15:22:02 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvW-0000kV-1j for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:02 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvV-00C7Ax-EK for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:01 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a905610-e002-0a2a0a5209dd-0a2a450bc196-10 for ; Thu, 27 Aug 2026 17:22:01 +0200 Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a905619-b7e8-0a2a450b0019-d155802fed17-3 for ; Thu, 27 Aug 2026 17:22:01 +0200 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-4998b5a63e2so21331925e9.1 for ; Thu, 27 Aug 2026 08:22:01 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.21.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:00 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844121; x=1788448921; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=2V2WJTxwQddlTB5GIlNmFwYUX3diFnW07Uicf4Tu70o=; b=FaClzkYYck+vnVVTLwLLEmurK4/wnx2HP3kdm8bx5OyleS1Puw61+p3SaDRjKgR7Gv UuYyu7WSPJRP5y0FruQCvlPz7ovNn//GgxnJWPN43MR1yIEPyH5T1OG5p8dqiSsFuYyS Nub8ER1J2YHvzTCmU0BZLd+K0UW05F07sYvvBsgJW1927Az+8QcVzEY/vPkAn+dwVim1 6Bz3t48gI/fxlRYdSfqyrCAozZmIgibr6EaJTy77ONtP3oaOWVh0Q3zlp5uumhWjfjFc 3RnUNjzrd0Vq56wEZ4FIAt2OTEG/TtaU1sdRit9yAfI0HsNmpXhRUeGhTCDXiqjCD9Jh DnRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844121; x=1788448921; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=2V2WJTxwQddlTB5GIlNmFwYUX3diFnW07Uicf4Tu70o=; b=QPN6Uioz2ek/BEw+NVc+y/RAtmTOYiaPSI1ggsL46TvSvzLowNB95x2xgUrv+zNAha 3c4dHAdm81gxsZNrPFVL9N+MmL2WtinbyeNO3idDp3S4iglAN2srrVozWG8toAG1dcdv LiCOagESrbizeZFQDyI9otSOVogVWhDMvsrDYf3l+ImAZGpiSxYaEvD2W3L22eDOnM9y GlenQsWgBowmkTlOy2B0GGMFjAcEkBbOF6el6lpAmvQJ/5nwS+s2+rli0F46w5eKV3Ae 9V4vfoPRSGlLyCGkd5ZzujLzTSoGCVMsGbYfbHppoFRfJlRUFo/hcQsT8bC7Y1mrxPp6 XFsw== X-Gm-Message-State: AFuF++lrS2OcJtxs3q1Pbmc9rVrzA2cve9FsAGlqg6VcYhxz0l0hp5Kt GPknE+EAeD+0rlOpMqL8cOrlcuAeAufKbysxBS7Fn+qkNXmC4j+7d8gKkpwOoA== X-Gm-Gg: AR+sD11cL9BhTITHLLQ6ayzwaxhcAbEDpwjurRXlNMRNjz5YFmxLNCLqbw2poOcdi+P WWS6Iykqu3xiLtQwtwhQftG7kD/iW/nOdVncy4Dp2ATYodVAFipxxYHXK7DtZYZyyBS+NROX3o9 O6QcfXfbMXKYt/GTY5rSphEg2NA6LAcZWZmfiel//bhN7JHQULcqxPGZ2uDweQ8b8PcoYz8sKDy B5GIlh3wUNuzP6JS50AEQVZdgmfPVrWer1bZL+dP7XBZCHmG6HgFXAnfMitrBPcWgzZEeR4wMLX wIu1jkTfpa63zDnLgqYnfg4gVoKi5P/jiB1RUEAvEj6pamazlc7d6vp4yZ31L9PXDR9TGUmRUW+ xwA5xEYemkCAxOJFZn2hd/ucjUCihkJqf2CDckKB8kzyAlRI0hDaHXaQ/NTZl3RObeVJdZCri9s HBZurfkugiyksWq9wr2/2SM3oRhEOwc3l1kTzhGTpJMSxBIurDcLPnBRPeokU+eqaCPq0I6Sv44 px0Yv3KI0iJR0hqBf1OpEG+XeYWm5Im X-Received: by 2002:a05:600c:c172:b0:49b:72e4:6223 with SMTP id 5b1f17b1804b1-49b72e463bdmr94379345e9.7.1787844120558; Thu, 27 Aug 2026 08:22:00 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 12/39] xen/riscv: implement vCPU context switching Date: Thu, 27 Aug 2026 17:20:56 +0200 Message-ID: <8848874c69f00fbfcf6ad75a39e28479a4cdd08b.1787838835.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-42698a/1787844121-1A6DA9EA-2496DA3C/10/73395122804 X-purgate-type: spam X-purgate-size: 19797 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844146315158500 Content-Type: text/plain; charset="utf-8" Implement context_switch() and the helpers it needs: save/restore of H/VS CSRs, virtual timer and P2M context, and __context_switch() in assembl= y, which switches Xen's own callee-saved state (and thereby the stack) from prev to next. Virtual interrupt controller context switch will be introduced later. Add offsets of struct arch_vcpu's xen_saved_context to asm-offsets.c for use by __context_switch(). henvcfg and htimedelta are 64-bit on both RV32 and RV64, so store them as uint64_t and use csr_{read,write}64() instead of open-coding accesses to the high halves. A hart which drops out of a domain's dirty_cpumask stops being a target of p2m_tlb_flush() while its TLB may still hold G-stage translations of that domain, and neither the vCPU which just ran nor any other vCPU of that domain which ran there earlier has had its VMID invalidated. Move the hart to a new VMID generation at that point: a VMID number is never re-used until a full local flush has happened, hence none of those translations can be reached again. Claim the VMID in p2m_ctxt_switch_to() rather than at the next guest entry. VMIDs are a per-hart resource, so the (generation, vmid) pair a migrating vCPU brings from another hart is meaningless here and may even match this hart's current generation, leaving the vCPU under a VMID owned by another domain. ctxt_switch_to() invalidates that pair, but claiming a replacement only on guest entry is too late: p2m_ctxt_switch_to() has by then already made HGATP live, and speculation can populate G-stage entries of the incoming domain under the stale VMID. The local flush for a wrapped generation moves along with the claim. That leaves p2m_handle_vmenter() with nothing to do, so drop it together with its call from check_for_pcpu_work(). A VMID can only be invalidated while its vCPU isn't running: vmid_flush_vcpu() is called for the vCPU being switched in, and vmid_flush_hart() runs either from schedule_tail(), ahead of ctxt_switch_to(), or from the wrap path of vmid_handle_vmenter() itself. A P2M change on another hart doesn't invalidate it either, as p2m_tlb_flush() drops the stale entries directly with sbi_remote_hfence_gvma() instead of retiring the VMIDs which tag them. A guest therefore always runs under the VMID claimed on its way in, and there is nothing left for a guest entry hook to notice. p2m_handle_vmenter() also skipped the HGATP write when the VMID it claimed was unchanged. That isn't carried over: HGATP holds the G-stage root as well, and skipping the write is only correct where that root is already the incoming domain's. On the guest entry path it is, on the context switch path it is not. While at it, fix the inclusion order of headers in asm-offsets.c: Xen's headers go first, then arch specific ones. Signed-off-by: Oleksii Kurochko --- Changes in v2: - New patch. --- --- xen/arch/riscv/domain.c | 167 +++++++++++++++++++++++++++ xen/arch/riscv/entry.S | 44 +++++++ xen/arch/riscv/include/asm/domain.h | 16 ++- xen/arch/riscv/include/asm/p2m.h | 1 - xen/arch/riscv/include/asm/system.h | 4 + xen/arch/riscv/p2m.c | 57 ++------- xen/arch/riscv/riscv64/asm-offsets.c | 19 ++- xen/arch/riscv/stubs.c | 5 - xen/arch/riscv/traps.c | 2 - 9 files changed, 258 insertions(+), 57 deletions(-) diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index ec327a5e8a23..91a46d630f44 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -11,9 +11,11 @@ #include #include #include +#include #include #include #include +#include #include =20 struct csr_masks { @@ -158,6 +160,8 @@ int arch_vcpu_create(struct vcpu *v) if ( is_idle_vcpu(v) ) return 0; =20 + v->arch.last_cpu =3D NR_CPUS; + vcpu_csr_init(v); =20 if ( (rc =3D vcpu_vtimer_init(v)) ) @@ -329,6 +333,169 @@ int arch_domain_create(struct domain *d, return rc; } =20 +static void save_csr_regs(struct vcpu *vcpu) +{ + /* + * There is no need to save these CSRs as only hypervisor writes them = in + * restore_csr_regs() and guest can't access them so they shouldn't be + * stored here. Keep them commented here just for symmetry with the + * restore CSRs register part. + * + * vcpu->arch.hedeleg =3D csr_read(CSR_HEDELEG); + * vcpu->arch.hideleg =3D csr_read(CSR_HIDELEG); + * vcpu->arch.henvcfg =3D csr_read64(CSR_HENVCFG); + * vcpu->arch.hcounteren =3D csr_read(CSR_HCOUNTEREN); + * vcpu->arch.htimedelta =3D csr_read64(CSR_HTIMEDELTA); + * + * if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) + * vcpu->arch.hstateen0 =3D csr_read(CSR_HSTATEEN0); + */ + + vcpu->arch.hvip =3D csr_read(CSR_HVIP); + + vcpu->arch.vsstatus =3D csr_read(CSR_VSSTATUS); + vcpu->arch.vsie =3D csr_read(CSR_VSIE); + vcpu->arch.vstvec =3D csr_read(CSR_VSTVEC); + vcpu->arch.vsscratch =3D csr_read(CSR_VSSCRATCH); + vcpu->arch.vscause =3D csr_read(CSR_VSCAUSE); + vcpu->arch.vstval =3D csr_read(CSR_VSTVAL); + vcpu->arch.vsepc =3D csr_read(CSR_VSEPC); +} + +static void restore_csr_regs(struct vcpu *vcpu) +{ + csr_write(CSR_HEDELEG, vcpu->arch.hedeleg); + csr_write(CSR_HIDELEG, vcpu->arch.hideleg); + csr_write(CSR_HVIP, vcpu->arch.hvip); + csr_write64(CSR_HENVCFG, vcpu->arch.henvcfg); + csr_write(CSR_HCOUNTEREN, vcpu->arch.hcounteren); + csr_write64(CSR_HTIMEDELTA, vcpu->arch.htimedelta); + + if ( riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) + csr_write(CSR_HSTATEEN0, vcpu->arch.hstateen0); + + csr_write(CSR_VSSTATUS, vcpu->arch.vsstatus); + csr_write(CSR_VSIE, vcpu->arch.vsie); + csr_write(CSR_VSTVEC, vcpu->arch.vstvec); + csr_write(CSR_VSSCRATCH, vcpu->arch.vsscratch); + csr_write(CSR_VSCAUSE, vcpu->arch.vscause); + csr_write(CSR_VSTVAL, vcpu->arch.vstval); + csr_write(CSR_VSEPC, vcpu->arch.vsepc); +} + +static void ctxt_switch_from(struct vcpu *p) +{ + /* + * When the idle VCPU is running, Xen will always stay in hypervisor + * mode. + * Therefore we don't need to save the context of an idle VCPU. + */ + if ( is_idle_vcpu(p) ) + return; + + p2m_ctxt_switch_from(p); + + vtimer_ctxt_switch_from(p); + + save_csr_regs(p); +} + +static void ctxt_switch_to(struct vcpu *n) +{ + /* + * When the idle VCPU is running, Xen will always stay in hypervisor + * mode. + * Therefore we don't need to restore the context of an idle VCPU. + */ + if ( is_idle_vcpu(n) ) + return; + + /* + * If this vCPU last ran on a different pCPU, invalidate its VMID so + * vmid_handle_vmenter() assigns a fresh one from the current pCPU's p= ool. + * Without this, two pCPUs could independently assign the same + * (generation, vmid) pair, generation counters start at the same value + * on all pCPUs and increment independently, causing TLB contamination. + */ + if ( n->arch.last_cpu !=3D smp_processor_id() ) + vmid_flush_vcpu(n); + + vtimer_ctxt_switch_to(n); + + restore_csr_regs(n); + + p2m_ctxt_switch_to(n); +} + +static void schedule_tail(struct vcpu *prev) +{ + unsigned int cpu =3D smp_processor_id(); + + ASSERT(prev !=3D current); + + ctxt_switch_from(prev); + + /* + * Mark this CPU in next domain's dirty cpumasks before calling + * ctxt_switch_to(). This avoids a race on things like p2m flushing, + * which is synchronised on that function. + */ + if ( prev->domain !=3D current->domain ) + { + cpumask_set_cpu(cpu, current->domain->dirty_cpumask); + + /* + * Once this hart drops out of prev's dirty_cpumask it stops being= a + * target of p2m_tlb_flush(), while its TLB may still hold G-stage + * translations of prev's domain: neither the vCPU which just ran = nor + * any other vCPU of that domain which ran here earlier has had its + * VMID invalidated. Move the hart to a new VMID generation so that + * none of them can be reached again. + * + * Switching away from the idle vCPU needs no bump: the idle domain + * has no p2m of its own, and whatever G-stage entries this hart m= ay + * still hold (or speculatively create while HGATP keeps pointing = at + * the last guest's p2m) are tagged with a VMID which was already = made + * stale when that guest was switched out. Skipping the bump here = also + * avoids burning a generation on every pass through idle. + */ + if ( !is_idle_vcpu(prev) ) + vmid_flush_hart(); + + cpumask_clear_cpu(cpu, prev->domain->dirty_cpumask); + } + write_atomic(¤t->dirty_cpu, cpu); + + ctxt_switch_to(current); + + write_atomic(&prev->dirty_cpu, VCPU_CPU_CLEAN); + + current->arch.last_cpu =3D cpu; + + /* + * sched_context_switched() internally uses a spinlock, + * which requires interrupts to be enabled. + */ + local_irq_enable(); + + sched_context_switched(prev, current); +} + +void context_switch(struct vcpu *prev, struct vcpu *next) +{ + ASSERT(local_irq_is_enabled()); + ASSERT(prev !=3D next); + ASSERT(!vcpu_cpu_dirty(next)); + + local_irq_disable(); + + set_current(next); + + prev =3D __context_switch(prev, next); + + schedule_tail(prev); +} + static void __init __maybe_unused build_assertions(void) { /* diff --git a/xen/arch/riscv/entry.S b/xen/arch/riscv/entry.S index 202a35fb03a8..331446a238d3 100644 --- a/xen/arch/riscv/entry.S +++ b/xen/arch/riscv/entry.S @@ -99,3 +99,47 @@ restore_registers: =20 sret END(handle_trap) + +/* + * struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next) + * + * This is called on prev's stack, and returns on next's. + * + * a0 - prev + * a1 - next + * + * Returns prev in a0 + */ +FUNC(__context_switch) + REG_S s0, VCPU_XEN_SAVED_CONTEXT_S0(a0) + REG_S s1, VCPU_XEN_SAVED_CONTEXT_S1(a0) + REG_S s2, VCPU_XEN_SAVED_CONTEXT_S2(a0) + REG_S s3, VCPU_XEN_SAVED_CONTEXT_S3(a0) + REG_S s4, VCPU_XEN_SAVED_CONTEXT_S4(a0) + REG_S s5, VCPU_XEN_SAVED_CONTEXT_S5(a0) + REG_S s6, VCPU_XEN_SAVED_CONTEXT_S6(a0) + REG_S s7, VCPU_XEN_SAVED_CONTEXT_S7(a0) + REG_S s8, VCPU_XEN_SAVED_CONTEXT_S8(a0) + REG_S s9, VCPU_XEN_SAVED_CONTEXT_S9(a0) + REG_S s10, VCPU_XEN_SAVED_CONTEXT_S10(a0) + REG_S s11, VCPU_XEN_SAVED_CONTEXT_S11(a0) + REG_S sp, VCPU_XEN_SAVED_CONTEXT_SP(a0) + REG_S ra, VCPU_XEN_SAVED_CONTEXT_RA(a0) + + REG_L s0, VCPU_XEN_SAVED_CONTEXT_S0(a1) + REG_L s1, VCPU_XEN_SAVED_CONTEXT_S1(a1) + REG_L s2, VCPU_XEN_SAVED_CONTEXT_S2(a1) + REG_L s3, VCPU_XEN_SAVED_CONTEXT_S3(a1) + REG_L s4, VCPU_XEN_SAVED_CONTEXT_S4(a1) + REG_L s5, VCPU_XEN_SAVED_CONTEXT_S5(a1) + REG_L s6, VCPU_XEN_SAVED_CONTEXT_S6(a1) + REG_L s7, VCPU_XEN_SAVED_CONTEXT_S7(a1) + REG_L s8, VCPU_XEN_SAVED_CONTEXT_S8(a1) + REG_L s9, VCPU_XEN_SAVED_CONTEXT_S9(a1) + REG_L s10, VCPU_XEN_SAVED_CONTEXT_S10(a1) + REG_L s11, VCPU_XEN_SAVED_CONTEXT_S11(a1) + REG_L sp, VCPU_XEN_SAVED_CONTEXT_SP(a1) + REG_L ra, VCPU_XEN_SAVED_CONTEXT_RA(a1) + + ret +END(__context_switch) diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/a= sm/domain.h index 15e8fa19685e..90ed584bb844 100644 --- a/xen/arch/riscv/include/asm/domain.h +++ b/xen/arch/riscv/include/asm/domain.h @@ -29,6 +29,12 @@ struct arch_vcpu_io { struct arch_vcpu { struct vcpu_vmid vmid; =20 + /* + * The last CPU this vCPU ran on. Initialised to NR_CPUS + * (never ran). + */ + unsigned int last_cpu; + /* * Callee saved registers for Xen's state used to switch from * prev's stack to the next's stack during context switch. @@ -60,11 +66,19 @@ struct arch_vcpu { register_t hcounteren; register_t hedeleg; register_t hideleg; - register_t henvcfg; + uint64_t henvcfg; register_t hstateen0; + uint64_t htimedelta; register_t hvip; =20 register_t vsatp; + register_t vscause; + register_t vsepc; + register_t vsie; + register_t vsscratch; + register_t vsstatus; + register_t vstval; + register_t vstvec; =20 /* * VCPU interrupts diff --git a/xen/arch/riscv/include/asm/p2m.h b/xen/arch/riscv/include/asm/= p2m.h index 0d1dace1a0d8..9edf78377ee5 100644 --- a/xen/arch/riscv/include/asm/p2m.h +++ b/xen/arch/riscv/include/asm/p2m.h @@ -262,7 +262,6 @@ struct page_info *p2m_get_page_from_gfn(struct p2m_doma= in *p2m, gfn_t gfn, =20 void p2m_ctxt_switch_from(struct vcpu *p); void p2m_ctxt_switch_to(struct vcpu *n); -void p2m_handle_vmenter(void); =20 #endif /* ASM__RISCV__P2M_H */ =20 diff --git a/xen/arch/riscv/include/asm/system.h b/xen/arch/riscv/include/a= sm/system.h index f33af64fd2ec..f5f30a9c8059 100644 --- a/xen/arch/riscv/include/asm/system.h +++ b/xen/arch/riscv/include/asm/system.h @@ -76,6 +76,10 @@ static inline bool local_irq_is_enabled(void) =20 #define arch_fetch_and_add(x, v) __sync_fetch_and_add(x, v) =20 +struct vcpu; + +struct vcpu *__context_switch(struct vcpu *prev, struct vcpu *next); + #endif /* __ASSEMBLER__ */ =20 #endif /* ASM__RISCV__SYSTEM_H */ diff --git a/xen/arch/riscv/p2m.c b/xen/arch/riscv/p2m.c index de25607247a6..1f7a6907525d 100644 --- a/xen/arch/riscv/p2m.c +++ b/xen/arch/riscv/p2m.c @@ -1504,13 +1504,12 @@ void p2m_ctxt_switch_from(struct vcpu *p) * VMID, world-switch code should zero vsatp, then swap hgatp, then * finally write the new vsatp value what will be done in * p2m_ctxt_switch_to(). - * Note, that also HGATP update could happen in p2m_handle_vmenter(). */ p->arch.vsatp =3D csr_swap(CSR_VSATP, 0); =20 /* - * Nothing to do with HGATP as it will be update in p2m_ctxt_switch_to= () - * or/and in p2m_handle_vmenter(). + * Nothing to do with HGATP as it will be updated in + * p2m_ctxt_switch_to(). */ } =20 @@ -1524,15 +1523,21 @@ void p2m_ctxt_switch_from(struct vcpu *p) void p2m_ctxt_switch_to(struct vcpu *n) { struct p2m_domain *p2m =3D p2m_get_hostp2m(n->domain); + bool need_flush; =20 if ( is_idle_vcpu(n) ) return; =20 + need_flush =3D vmid_handle_vmenter(&n->arch.vmid); + csr_write(CSR_HGATP, construct_hgatp(p2m, n->arch.vmid.vmid)); + /* - * As VMID is unique per vCPU and just re-used here thereby there is no - * need for G-stage TLB flush here. + * A VMID isn't re-used until the generation it was issued in wraps, so + * a G-stage flush is needed only when vmid_handle_vmenter() says so. */ + if ( unlikely(need_flush) ) + local_hfence_gvma_all(); =20 csr_write(CSR_VSATP, n->arch.vsatp); =20 @@ -1548,48 +1553,6 @@ void p2m_ctxt_switch_to(struct vcpu *n) flush_tlb_guest_local(); } =20 -void p2m_handle_vmenter(void) -{ - struct vcpu *curr =3D current; - struct p2m_domain *p2m =3D p2m_get_hostp2m(curr->domain); - struct vcpu_vmid *p_vmid =3D &curr->arch.vmid; - unsigned short old_vmid, new_vmid; - bool need_flush; - - BUG_ON(is_idle_vcpu(curr)); - - old_vmid =3D p_vmid->vmid; - need_flush =3D vmid_handle_vmenter(p_vmid); - new_vmid =3D p_vmid->vmid; - -#ifdef P2M_DEBUG - printk("%pv: oldvmid(%d) new_vmid(%d), need_flush(%d)\n", - curr, old_vmid, new_vmid, need_flush); -#endif - - /* - * There is no need to set VSATP to 0 to stop speculation before updat= ing - * HGATP, as VSATP is not modified here. - */ - if ( old_vmid !=3D new_vmid ) - csr_write(CSR_HGATP, construct_hgatp(p2m, p_vmid->vmid)); - - /* - * There is also no need to flush G-stage TLB unconditionally as old V= MID - * won't be reused until need_flush is set to true. - */ - if ( unlikely(need_flush) ) - local_hfence_gvma_all(); - - /* - * There is also no need to flush the VS-stage TLB: even if speculation - * occurs (VSATP + old HGATP were used), it will use the old VMID, whi= ch - * won't be reused until need_flush is set to true. When VMIDs aren't - * available there is no old VMID to rely on, but then need_flush is s= et - * on every entry, so the flush above covers that case. - */ -} - struct page_info *get_page_from_gfn(struct domain *d, unsigned long gfn, p2m_type_t *t, p2m_query_t q) { diff --git a/xen/arch/riscv/riscv64/asm-offsets.c b/xen/arch/riscv/riscv64/= asm-offsets.c index 1290b9dbbe82..c1be1614ce94 100644 --- a/xen/arch/riscv/riscv64/asm-offsets.c +++ b/xen/arch/riscv/riscv64/asm-offsets.c @@ -1,8 +1,10 @@ #define COMPILE_OFFSETS =20 +#include +#include + #include #include -#include =20 #define DEFINE(_sym, _val) = \ asm volatile ( "\n.ascii\"=3D=3D>#define " #_sym " %0 /* " #_val " */<= =3D=3D\""\ @@ -53,4 +55,19 @@ void asm_offsets(void) BLANK(); DEFINE(PCPU_INFO_SIZE, sizeof(struct pcpu_info)); BLANK(); + OFFSET(VCPU_XEN_SAVED_CONTEXT_S0, struct vcpu, arch.xen_saved_context.= s0); + OFFSET(VCPU_XEN_SAVED_CONTEXT_S1, struct vcpu, arch.xen_saved_context.= s1); + OFFSET(VCPU_XEN_SAVED_CONTEXT_S2, struct vcpu, arch.xen_saved_context.= s2); + OFFSET(VCPU_XEN_SAVED_CONTEXT_S3, struct vcpu, arch.xen_saved_context.= s3); + OFFSET(VCPU_XEN_SAVED_CONTEXT_S4, struct vcpu, arch.xen_saved_context.= s4); + OFFSET(VCPU_XEN_SAVED_CONTEXT_S5, struct vcpu, arch.xen_saved_context.= s5); + OFFSET(VCPU_XEN_SAVED_CONTEXT_S6, struct vcpu, arch.xen_saved_context.= s6); + OFFSET(VCPU_XEN_SAVED_CONTEXT_S7, struct vcpu, arch.xen_saved_context.= s7); + OFFSET(VCPU_XEN_SAVED_CONTEXT_S8, struct vcpu, arch.xen_saved_context.= s8); + OFFSET(VCPU_XEN_SAVED_CONTEXT_S9, struct vcpu, arch.xen_saved_context.= s9); + OFFSET(VCPU_XEN_SAVED_CONTEXT_S10, struct vcpu, arch.xen_saved_context= .s10); + OFFSET(VCPU_XEN_SAVED_CONTEXT_S11, struct vcpu, arch.xen_saved_context= .s11); + OFFSET(VCPU_XEN_SAVED_CONTEXT_SP, struct vcpu, arch.xen_saved_context.= sp); + OFFSET(VCPU_XEN_SAVED_CONTEXT_RA, struct vcpu, arch.xen_saved_context.= ra); + BLANK(); } diff --git a/xen/arch/riscv/stubs.c b/xen/arch/riscv/stubs.c index 3a7953593d93..e0febae432b2 100644 --- a/xen/arch/riscv/stubs.c +++ b/xen/arch/riscv/stubs.c @@ -81,11 +81,6 @@ void smp_send_state_dump(unsigned int cpu) =20 DEFINE_PER_CPU(struct vcpu *, curr_vcpu); =20 -void context_switch(struct vcpu *prev, struct vcpu *next) -{ - BUG_ON("unimplemented"); -} - void continue_running(struct vcpu *same) { BUG_ON("unimplemented"); diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c index 8530e6fbda0a..093d81e2d803 100644 --- a/xen/arch/riscv/traps.c +++ b/xen/arch/riscv/traps.c @@ -178,8 +178,6 @@ static void check_for_pcpu_work(void) vcpu_sync_interrupts(curr); =20 vcpu_flush_interrupts(curr); - - p2m_handle_vmenter(); } =20 static void timer_interrupt(void) --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844170; cv=none; d=zohomail.com; s=zohoarc; b=RYeEbe0pI0a5N8RZNhAxBOkKE9zexQkA7rCHm87Cq13W8tVQU+cmXIZx9ZQ3lT6v1WwUdaVM6OygPJ2ySSwFBoebbPKeYiAyyQMRYPA8mjKYjRKceS75w8qztPXb2Fzj1idpZlq0IY5Z3TFh50gDGyNmz3tVQMNpLgp0ZKA14kA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844170; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=dwcuML5F9XLKwrpF1mZ2DXW4eSQt83hnQQahtTCbafI=; b=PmeREmKXI5JKn8zm3C3NsCQkxcVf1DvTFI6U7vCRD2/sQoDPG6tJ3pZhFetURBfs4xfkB/mbOhb+CEeYAsMvyQDfL98lK2Yysqw9+qcwST+bqHU1PI8wu0j/E9KmnsZys7yGzMDwmHb4+pepjP6UqcOHseizv6+yCvsWkayrWAw= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844170587890.3573246336379; Thu, 27 Aug 2026 08:22:50 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400943.1636656 (Exim 4.92) (envelope-from ) id 1wzbvZ-0001J2-0a; Thu, 27 Aug 2026 15:22:05 +0000 Received: by outflank-mailman (output) from mailman id 1400943.1636656; Thu, 27 Aug 2026 15:22:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbvY-0001Hu-QM; Thu, 27 Aug 2026 15:22:04 +0000 Received: by outflank-mailman (input) for mailman id 1400943; Thu, 27 Aug 2026 15:22:03 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvX-00013X-Mu for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:03 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvX-009kzH-3C for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:03 +0200 Received: from [10.42.69.4] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a90560b-2eae-0a2a0a5409dd-0a2a45048a6e-44 for ; Thu, 27 Aug 2026 17:22:03 +0200 Received: from [209.85.128.45] (helo=mail-wm1-f45.google.com) by tlsNG-ebf023.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a90561a-b57f-0a2a45040019-d155802dd03a-3 for ; Thu, 27 Aug 2026 17:22:03 +0200 Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-49b392ccaacso11904575e9.2 for ; Thu, 27 Aug 2026 08:22:03 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:01 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844122; x=1788448922; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=dwcuML5F9XLKwrpF1mZ2DXW4eSQt83hnQQahtTCbafI=; b=hTLN+ijTUr71vCQNwUHIndJ1NXM3wB5CTDh6jpYcq33MrRvhkGNTYbUMmJ06SWRTxB 1ckanvOv73GdhMe4vFx1Xw6yPHITgT22LJDNIHl155HWcpcxGdEspfDjxFpSizbuX+Vc RU/UiEEAwhFyJ1k7p+KeeBNE2y847pn4TizFQy3TGoRMmUrIQUHWExrwmtbtBdeMGfc7 MBjR4qWzQ8m0l4lhP3cRyJh9I/dWtO99+MsoH79ItxmDZUuDTnNysEqv06xnIS4k3zvj kGxyNTWeMkAlvO5zNQJXvT8a2Huk5Msc5y5JdIYcG8qo4KWK0qKCszpWTMGEoamuft+I /T6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844122; x=1788448922; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=dwcuML5F9XLKwrpF1mZ2DXW4eSQt83hnQQahtTCbafI=; b=PiDA+s37zozQJuPFU+ty2qlaomPwRmtfgxoOipOvatKjmWVXY7Ep1Y+KhuTC97u4F7 kv0z8qfJeJLcICtI+SPvwI1otdf/N4w40QtjBuJzpHpMZ79BgpDlz723iiET0DEAJzH6 eoESm1YIx05A6jFHuznEdqCl5Nryzd9f12v5T+MQbTDgJenWyXbNyWEejhibTZD1/hgx L0AC2+a8AjQIuaOH3N1yBonK8CmWn2L0oJ6vV3ndKt0KlpAvltpdqwpafXChKjsY80/a Kw1vn6v4FEl8IEi06hQeW+sijU8rLXsAbl6gbeOoCCbweseXObLQXNueT0Qglby8RjY6 aF+A== X-Gm-Message-State: AFuF++mQuobzDADWO/BY4pEG6a3RDAeAZgz0FWSAIvkkf0YlZix4EyOA xfbH7aA8rwanh9/ZqOvKAS3BYKskUrsMpcwYDH8AnyLpwS24NUlCb+rnYfVtdQ== X-Gm-Gg: AR+sD10TxDEQd41yYsl83tK9KFfjaoNW5gvSebqw5Fygw7b+u9sI8aN6/FmvFET0rgq ej9+vg+OTt3alhi4kDlHRYlBic0w1uuU6rUILUJY7Ny15/RcauioSv6rV8WzDtKOxPETqqwoz3m IaFQofPAVFDFkbIYOKYkr0AewTrTREcBkIu+AA9eX89/H9tELu7j2NVeJUN6Uc26XLZALaqZpYe 4ku2YU+tOm274OA76I3ESnAMRw3/GrqdWghd2EqEnzVAgSftmD3Ze4flATD/gvJxJkwby+yWt3t lYIVolwNVVt90IlXPS79688fooAC/+UitP2putPfla/lapY7ZC+Q2PDoz4wcXlnnFlchkbF7Ic/ tX4o6NsqXqMT6tYRKfIMdw/aiZIrXn1jYlTdhPBrPJD7naEFTILKbODCq+ljKEjZYvdMSVMRnxZ eaX/LmNQFx/brhpi6PsFFIWjeF/E6i6BI6tT3yoW1YAY9ZlwQtfjtIP80JwpOHMCYQHSLR/U9cI ori7wcPx17DnMZUiZheDogeUL0KLJ3XIyCRkFz+FJs= X-Received: by 2002:a05:600c:3485:b0:49a:77c1:d246 with SMTP id 5b1f17b1804b1-49a77c1d2eemr170533355e9.15.1787844122118; Thu, 27 Aug 2026 08:22:02 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 13/39] xen/riscv: save and restore AIA state on vCPU context switch Date: Thu, 27 Aug 2026 17:20:57 +0200 Message-ID: <32e8b81fd276498cfd339defd2720bce1745c1cf.1787838835.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-ebf023/1787844123-52ECEB50-08C9A4FF/10/73395122804 X-purgate-type: spam X-purgate-size: 4978 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844172413158500 Content-Type: text/plain; charset="utf-8" vsiselect and hviprio{1,2} are per-hart CSRs which a guest can change, so they have to be part of the vCPU context: - vsiselect is written directly by VS-mode through siselect; - hviprio1 and hviprio2 hold the priorities of the local interrupts which VS-mode reaches through the iprio array of vsiselect/vsireg, so writes the guest performs there land in these CSRs. Without saving them, one vCPU's selector leaks into another vCPU's vsireg accesses and one guest's interrupt priorities apply to the next guest which runs on the same hart. Whether the CSRs may be touched at all is gated by hstateen0 when Smstateen is implemented: SVSLCT for vsiselect/vsireg and AIA for the rest of the AIA state. A bit staying clear in v->arch.hstateen0 means M-mode denied the access (see vcpu_csr_init()), and in that case the CSR can't be accessed from HS-mode either, hence the gating helper. vsie, hviprio1 and hviprio2 are 64-bit registers on both RV32 and RV64, so store them as uint64_t and use csr_{read,write}64() rather than truncating them to XLEN. Signed-off-by: Oleksii Kurochko --- Changes in v2: - New patch. --- --- xen/arch/riscv/domain.c | 44 +++++++++++++++++++++++++++-- xen/arch/riscv/include/asm/domain.h | 5 +++- 2 files changed, 46 insertions(+), 3 deletions(-) diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index 91a46d630f44..4afdfb4d09ab 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -333,6 +333,28 @@ int arch_domain_create(struct domain *d, return rc; } =20 +/* + * vsiselect and hviprio{1,2} are per-hart, but the guest can change them: + * vsiselect directly through siselect, and hviprio{1,2} through the iprio + * array which vsiselect/vsireg give VS-mode access to. Hence they are part + * of the vCPU context. + * + * When Smstateen is implemented, hstateen0 gates that access: SVSLCT for + * vsiselect/vsireg and AIA for the rest of the AIA state. A bit staying c= lear + * in v->arch.hstateen0 means M-mode denied it (see vcpu_csr_init()), and = then + * the corresponding CSR can't be accessed from HS-mode either. + */ +static bool vcpu_has_aia_state(const struct vcpu *v, register_t hstateen0_= bit) +{ + if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_ssaia) ) + return false; + + if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_smstateen) ) + return true; + + return v->arch.hstateen0 & hstateen0_bit; +} + static void save_csr_regs(struct vcpu *vcpu) { /* @@ -354,12 +376,21 @@ static void save_csr_regs(struct vcpu *vcpu) vcpu->arch.hvip =3D csr_read(CSR_HVIP); =20 vcpu->arch.vsstatus =3D csr_read(CSR_VSSTATUS); - vcpu->arch.vsie =3D csr_read(CSR_VSIE); + vcpu->arch.vsie =3D csr_read64(CSR_VSIE); vcpu->arch.vstvec =3D csr_read(CSR_VSTVEC); vcpu->arch.vsscratch =3D csr_read(CSR_VSSCRATCH); vcpu->arch.vscause =3D csr_read(CSR_VSCAUSE); vcpu->arch.vstval =3D csr_read(CSR_VSTVAL); vcpu->arch.vsepc =3D csr_read(CSR_VSEPC); + + if ( vcpu_has_aia_state(vcpu, SMSTATEEN0_SVSLCT) ) + vcpu->arch.vsiselect =3D csr_read(CSR_VSISELECT); + + if ( vcpu_has_aia_state(vcpu, SMSTATEEN0_AIA) ) + { + vcpu->arch.hviprio1 =3D csr_read64(CSR_HVIPRIO1); + vcpu->arch.hviprio2 =3D csr_read64(CSR_HVIPRIO2); + } } =20 static void restore_csr_regs(struct vcpu *vcpu) @@ -375,12 +406,21 @@ static void restore_csr_regs(struct vcpu *vcpu) csr_write(CSR_HSTATEEN0, vcpu->arch.hstateen0); =20 csr_write(CSR_VSSTATUS, vcpu->arch.vsstatus); - csr_write(CSR_VSIE, vcpu->arch.vsie); + csr_write64(CSR_VSIE, vcpu->arch.vsie); csr_write(CSR_VSTVEC, vcpu->arch.vstvec); csr_write(CSR_VSSCRATCH, vcpu->arch.vsscratch); csr_write(CSR_VSCAUSE, vcpu->arch.vscause); csr_write(CSR_VSTVAL, vcpu->arch.vstval); csr_write(CSR_VSEPC, vcpu->arch.vsepc); + + if ( vcpu_has_aia_state(vcpu, SMSTATEEN0_SVSLCT) ) + csr_write(CSR_VSISELECT, vcpu->arch.vsiselect); + + if ( vcpu_has_aia_state(vcpu, SMSTATEEN0_AIA) ) + { + csr_write64(CSR_HVIPRIO1, vcpu->arch.hviprio1); + csr_write64(CSR_HVIPRIO2, vcpu->arch.hviprio2); + } } =20 static void ctxt_switch_from(struct vcpu *p) diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/a= sm/domain.h index 90ed584bb844..23e301782068 100644 --- a/xen/arch/riscv/include/asm/domain.h +++ b/xen/arch/riscv/include/asm/domain.h @@ -70,11 +70,14 @@ struct arch_vcpu { register_t hstateen0; uint64_t htimedelta; register_t hvip; + uint64_t hviprio1; + uint64_t hviprio2; =20 register_t vsatp; register_t vscause; register_t vsepc; - register_t vsie; + uint64_t vsie; + register_t vsiselect; register_t vsscratch; register_t vsstatus; register_t vstval; --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844143; cv=none; d=zohomail.com; s=zohoarc; b=Lz/hIkvNm/XwAmOAsPhDB2JM5ecPhqkgu0Z9wpRVPWjpP/H69RziGUVlw4jXLoG05ihl0pTWGfPtpWaP9LP0PLe5fcUL43IuDzGwbeuH/M4QUmZgNhCSm7cVq//FQcUzrmNCYfkYy7sQFcOtdMlmYNLSaG7nXIV/SitNkUoGTlU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844143; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=1/cMuzGiRGtxRlpn3+ui4ui24plARkRR3MSniQJflTQ=; b=SemHkMH3Ksy/u4jvY/KzAiUSzvsmEDjZZge30NVmf4vj4TBP+opFVppGlHqXS7fEvNQrQYSgCc3+c76AJaOejIJBoGh6D6sPzs0LPSi5mszEp/p6hyLTbqlnE0owiQ4Kj7DWtEGMIYVJXr1GixQK2RhebqwW/KBWWyguRqspjA8= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844143822838.2509968601305; Thu, 27 Aug 2026 08:22:23 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400944.1636664 (Exim 4.92) (envelope-from ) id 1wzbva-0001b9-HZ; Thu, 27 Aug 2026 15:22:06 +0000 Received: by outflank-mailman (output) from mailman id 1400944.1636664; Thu, 27 Aug 2026 15:22:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbva-0001Zu-8B; Thu, 27 Aug 2026 15:22:06 +0000 Received: by outflank-mailman (input) for mailman id 1400944; Thu, 27 Aug 2026 15:22:04 +0000 Received: from mx.expurgate.net ([194.145.224.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvY-0001HL-Qy for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:04 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvY-00FiCE-79 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:04 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a90560c-bab6-0a2a0a5309dd-0a2a450c9cc8-38 for ; Thu, 27 Aug 2026 17:22:04 +0200 Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a90561c-f479-0a2a450c0019-d1558036a425-3 for ; Thu, 27 Aug 2026 17:22:04 +0200 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-49b0eab380eso10265215e9.0 for ; Thu, 27 Aug 2026 08:22:04 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:03 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844123; x=1788448923; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=1/cMuzGiRGtxRlpn3+ui4ui24plARkRR3MSniQJflTQ=; b=H7Vl3QnoRDAuDIz1nyu5Z9k7CKYFKxZcxeBVF6SUnSz87n9Lm5qiF5SI8Hyr/ikLDp 4pPKkdWpfkZg77PyT3JTE8G8jknG6ntwh2Q0s/ss2hrBWD26Z+1Tk95iP2Af93um/CZe 8Mw+ulxgsSQAnYE9rZRS0kUAfGWVkfwQRmEMih83auHURs+qsmbLF1/Tm+cUtOxV8dIQ c4HKRJuHylknOPfQxx5MuIj64YkwjTD6OMnbxwkrWoXSRpayj4YD5itz8DgUKg9NHR2/ IlW0G9s0o04FBlHmCipBpnyroYqVkNtzgotfbP7QiXwOkaP1/4Ky06RO8/BoBLKHOSST w2zQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844123; x=1788448923; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=1/cMuzGiRGtxRlpn3+ui4ui24plARkRR3MSniQJflTQ=; b=EwDb4umKqjZtQHjdMv3GpJdnM4S0Na3Fn3RKz8lsMLbX/8wPn4JcKYtekSz+G9UqOs XKlcordXVYH1WsByEhNpNfHU153ks1Aemi3YWjSxGJv4GlvE8Hm2DftJBv1E4a4yo+wc DsEp//k163vTo8lxx9ErlkIbPlMSUpac32ZoWpRCPUxpOlvGxpeBCKMOiJAHG/Jzrr03 YRr3Tx6onHTQ+BHpnZqJsY/pthHr33IxtE97/KZrFLxuoO6xl578dvxv0jArzNoRtVG0 FRAamxV2wqCNruuHvWszt0HcaFtXJGvX0yyd2vwF4cwnwVdN457EOw7DfQ316U0Rj4N8 +MVA== X-Gm-Message-State: AFuF++kvuudqkyVm9uXCytsZSfvekOH8zeDe47IhSTViB0doNmcgrI1X VI84nF75Ivh6RdK5hKKsSb0vfFidnn3OYxhC5/3+gNY3p9WT8e7X9OAadDwK+Q== X-Gm-Gg: AR+sD136TzbLQSvCv6PevKYnZCaYmKOOu9dwWsbCF5t0+1Asgm7KqXf61p4XUZAQR06 LiwOdMyigu8P+zK6PcIq28gOA42zedDGxohFbg6cduiN502OJTVcR7UJajCEOa2YsURMwjvp/0/ 4QtfxcLT4Aykw2DgqOuD0VjC6XCp94V4a5PVfGCfnXI8IAEV/49OOgXi6m1tEKmowm86CChSr/c Gd8yVFkgcrf/QMvaxlySKn0S6qzLE8dpX1mbSD2ZsnUr1A8UNJ2OChcLm7A/+m9IUCuEZV0jBFl g3OR6AXMSA94jiKo5QahHRK362uaUotIQlfZdPai/5C8MgPmhYu1IDbXW5vwA018W0WHQRDixPA 99hzksOEtxucN+f6KY6D5F/1mMsaM7w1Nu7cNwIF5y1FM1Vo/Wty0FikwPZ448t1ywgL0TuMPsb 5fGluccqAcWnLts5ubDdCC/1HFIXxq29stHcEnq+vhhlxbsEKWUE+daww2DOuwupPNcZ/T4TDhs DVMzbG9YhLW4EPE2pCgQ/cWvijGaoY6 X-Received: by 2002:a05:600c:3e8e:b0:499:5f80:83ac with SMTP id 5b1f17b1804b1-49b0dfd7d2cmr103580565e9.7.1787844123551; Thu, 27 Aug 2026 08:22:03 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 14/39] xen/riscv: introduce vintc_ctxt_switch_{from,to}() Date: Thu, 27 Aug 2026 17:20:58 +0200 Message-ID: <678236568970b18a1924a76588c4c50f9bf0c659.1787838835.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d25034/1787844124-026DEA5B-2FCEC2F6/10/73395122804 X-purgate-type: spam X-purgate-size: 2995 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844144247158500 Content-Type: text/plain; charset="utf-8" Virtual interrupt controller state must be preserved across vCPU context switches. Introduce vintc_ctxt_switch_{from,to}() wrappers around new ctxt_switch_{from,to}() hooks in struct vintc_ops, and call them from the context switch path, so that this state can be saved/restored without knowing which vINTC variant a domain uses. No vINTC variant implements the hooks yet: the vAPLIC implementation is added separately. Signed-off-by: Oleksii Kurochko --- Changes in v2: - Update the commit message. - s/vintc_state_{save,restore}/vintc_ctxt_switch_{to,from}. - s/{re}store_state/ctxt_switch_{to,from} for vintc_ops. - s/vcpu/v for vintc_ctxt_switch_{to,from}() arguments. --- --- xen/arch/riscv/domain.c | 4 ++++ xen/arch/riscv/include/asm/intc.h | 9 +++++++++ xen/arch/riscv/intc.c | 14 ++++++++++++++ 3 files changed, 27 insertions(+) diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index 4afdfb4d09ab..2dfe4c2e72ce 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -437,6 +437,8 @@ static void ctxt_switch_from(struct vcpu *p) =20 vtimer_ctxt_switch_from(p); =20 + vintc_ctxt_switch_from(p); + save_csr_regs(p); } =20 @@ -462,6 +464,8 @@ static void ctxt_switch_to(struct vcpu *n) =20 vtimer_ctxt_switch_to(n); =20 + vintc_ctxt_switch_to(n); + restore_csr_regs(n); =20 p2m_ctxt_switch_to(n); diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm= /intc.h index 1bfba7c6155b..62e1410156c7 100644 --- a/xen/arch/riscv/include/asm/intc.h +++ b/xen/arch/riscv/include/asm/intc.h @@ -64,6 +64,12 @@ struct vintc_ops { =20 /* Deinitialize some vINTC-related stuff for a vCPU */ void (*vcpu_deinit)(struct vcpu *v); + + /* Save vINTC state of the vCPU being switched out */ + void (*ctxt_switch_from)(struct vcpu *v); + + /* Restore vINTC state of the vCPU being switched in */ + void (*ctxt_switch_to)(struct vcpu *v); }; =20 struct vintc { @@ -91,4 +97,7 @@ void domain_vintc_deinit(struct domain *d); =20 int vintc_reserve_virq(const struct domain *d, unsigned int virq); =20 +void vintc_ctxt_switch_from(struct vcpu *v); +void vintc_ctxt_switch_to(struct vcpu *v); + #endif /* ASM__RISCV__INTERRUPT_CONTOLLER_H */ diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c index bca83b4f4fa3..9fff501b9c25 100644 --- a/xen/arch/riscv/intc.c +++ b/xen/arch/riscv/intc.c @@ -178,3 +178,17 @@ int __overlay_init vintc_reserve_virq(const struct dom= ain *d, =20 return test_and_set_bit(virq, d->arch.vintc->used_irqs) ? -EEXIST : 0; } + +void vintc_ctxt_switch_from(struct vcpu *v) +{ + const struct vintc_ops *ops =3D v->domain->arch.vintc->ops; + + ops->ctxt_switch_from(v); +} + +void vintc_ctxt_switch_to(struct vcpu *v) +{ + const struct vintc_ops *ops =3D v->domain->arch.vintc->ops; + + ops->ctxt_switch_to(v); +} --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844148; cv=none; d=zohomail.com; s=zohoarc; b=k5aja5Ns7T7LggMDC4TmWce+Gkp0mDBE+AVVWwz5Tky7yXk+y0OHYpmpbGYqXyGGQeWGa3j5DJM/y5zL6bH/7bSZeozusQXhrcjj2/H/LDakwLl/qbFjhv7WzRdGYnWwlr7NLL+SBNXboXSyb8xJ+T8nsLvb6O4k9NLyHVj8wMM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844148; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=MP0JcspPV6sKcJgpcXgzzdAfR5FcW+0ZqqcAyujXhtU=; b=lrOkI1+WXOhacjU9eXN/GHAQPd91l2aVrPZcL0nMnX18DDmCKGIawiXInNflitDFoAdD96ldPxFXe7AkB1ijVI5q3fBC/0QIcj7P5gL8Un9T1k6nY0AF/w7m1UpYwUrCBgIeEI44YXkngQVV3t6jx6EsC+xq0puwWSb4d8U3Fp4= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844148441874.8356158758868; Thu, 27 Aug 2026 08:22:28 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400946.1636674 (Exim 4.92) (envelope-from ) id 1wzbvc-00021q-Pk; Thu, 27 Aug 2026 15:22:08 +0000 Received: by outflank-mailman (output) from mailman id 1400946.1636674; Thu, 27 Aug 2026 15:22:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbvc-00021a-GS; Thu, 27 Aug 2026 15:22:08 +0000 Received: by outflank-mailman (input) for mailman id 1400946; Thu, 27 Aug 2026 15:22:06 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbva-0001WT-9C for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:06 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvZ-00C7Ax-MI for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:05 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a905610-e002-0a2a0a5209dd-0a2a450bc196-20 for ; Thu, 27 Aug 2026 17:22:05 +0200 Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a90561d-b7e8-0a2a450b0019-d1558032ec2b-3 for ; Thu, 27 Aug 2026 17:22:05 +0200 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-49b0d8bc2aaso14161565e9.0 for ; Thu, 27 Aug 2026 08:22:05 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:04 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844125; x=1788448925; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=MP0JcspPV6sKcJgpcXgzzdAfR5FcW+0ZqqcAyujXhtU=; b=mgCPd7fxOn+n9cxpsdDdRvMVzhdDH8bMhutCNYx0/W5UCP12vYOBTML/jjcKLK2mYB 61N52sPb55qF0DeMUgSEyQ0MwlsgBAI3n2vGbND3MgP34komKu8c2DeuAhRkwM7q52IT qY14CUPgTJcYtE99pWEBixY3zUqsfqun5Lptg9EI9OfDQMUmb2WEsxLjdh1p5fGXUKB1 MucNQ7inTyp6OyknAVKNC386e/P7w+D5ifxmnmQbNtEfiFnESDM8e0ZmR8EiJr6lacHu ooPBFqYTrDneiZWbQ4Ff55qzVB5D9W+jHsJS0U/Hc+gCaeREsflGLhbuCGm40woAZo7G 4zCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844125; x=1788448925; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=MP0JcspPV6sKcJgpcXgzzdAfR5FcW+0ZqqcAyujXhtU=; b=iLaNYR6E9vr58rti/pfhYrHXwxKkjL4WvdDbluL00D3WsNHTfNyLhA8LfP0wkEbp5O PRncefUmN6Hr+5bERJuz6mXyLoHK1v/HYkIga5/hbIF9dJCm2PQAqnuF6QYi0vKJgDzt l64dprmiuUw8wxTHFWLNEzeS9WaEUyBzuX8Vtn4f2y9PZLkTomwax/gVK24WdvZh2MnI iEAsecc4OppAWmuCyR83cXIYmZdZgmGd2dDEBftHZaiyZ1L2WKSHzfILxmInRdoIW85N avY9gdr0r9mOT2XYfICTkj0BaJPbf0LV17f9A3kFt9R9J75WZQs1hqKepZxysbReJZp5 5sig== X-Gm-Message-State: AFuF++lW0SnkbrnUy5hnlVr8whHBoEEI7jfiM7yZL+CCqfu2PIMtJlmY uCHqfBhCpzJUPZrkT4NWIsi6Kehf8RN9gl8j+rf2icm1K6c8xZ54xlqoCGMt5w== X-Gm-Gg: AR+sD13tLGY3fTVhWJGlipuo7MHbv1bFUXefvlcnpCRP2LLuaDWGdKYP9wBOhB3xGqe YT8NMmjsiOgX40bYQB5mGl110Nc+UzP0+RH4jG5/NPpA5N2pRcxPqyFTxJaME8b5pE6Ml67hr1S gUDc0MHiucZEFiM4xuo78V4wiioxDjgJqRo8bN1V3yhArunNTTqqQ1+xH9v63Rud4OYUF2AOiqi MPaphAMMAQZGRm4PCIow93pbku443K5iGI5neN8TEoCZ+RIK3l2PkvOr1BzLt0cl4HZeCTUVLwQ siIu0oR7976LtY08yOQsKbfog4AU/np5VQLx93xEQKcK/MvPEKYGzkoO+s2d41sAka9s52VxJwQ T4+CiP7DGTYHmT6bulI+o3EjhMfJGUyNEZnsr1IiCgs9+aJBoF1oYx+EnZZOFcgITieOGiKTH5+ 2wf0Zkf3+I9VOj361MIfT87GL2UyXJGdh5HF0l7vx/sklX+7H83yDwdsZFA93jw9RWxXl2Zc75q gO721wCq6KX2U9SKNY2BfuLhx7Qtpt0 X-Received: by 2002:a05:600c:8b77:b0:499:8ff5:8ecc with SMTP id 5b1f17b1804b1-499dc82fc0dmr217669995e9.15.1787844125025; Thu, 27 Aug 2026 08:22:05 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 15/39] xen/riscv: add IMSIC vCPU context switch handlers Date: Thu, 27 Aug 2026 17:20:59 +0200 Message-ID: <867af892784c295296cdf63e0371fa1b7ed7a1e7.1787838835.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-42698a/1787844125-AB8D19EA-408F7B20/10/73395122804 X-purgate-type: spam X-purgate-size: 4894 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844150281158500 Content-Type: text/plain; charset="utf-8" IMSIC state currently needs to track only which physical CPU owns a vCPU's IMSIC guest interrupt file, as the CPU id is part of the physical address the file is mapped at. Add imsic_ctxt_switch_from() to record that CPU when a vCPU is switched out. A vCPU running on the s/w VS-file has no h/w file bound to a CPU, so there is nothing to record for it. The recorded value stays unused until vCPU migration support, which needs it to find the file to move away from, is added later. imsic_ctxt_switch_to() has nothing to do: by the time a vCPU is switched in, VGEIN is already assigned to it and its guest interrupt file is already mapped. Work is only required once a vCPU can move to a different CPU, which means recalculating VGEIN and remapping the file; that is handled separately by the vCPU migration patches. Install both as the ctxt_switch_{from,to} hooks of struct vintc_ops. MSI delivery is the only mode Xen supports ( aplic_init() panics on an APLIC without an "msi-parent" property, and a guest's domaincfg.DM reads back as a fixed one) so the vAPLIC state to save and restore is always the IMSIC one and no vAPLIC-level forwarder is needed. Being indirect call targets, both handlers get cf_check. Co-developed-by: Romain Caritey Signed-off-by: Oleksii Kurochko --- Changes in v2: - s/imsic_state_{save,restore}/imsic_ctxt_switch_{from,to}: the old names suggested saving and restoring register state, which isn't what these functions do. - Fix the comment in imsic_ctxt_switch_from(): it explained the ->vsfile_cpu sentinel while the code checks ->guest_file_id. - Adapt to ->vsfile_cpu holding v->processor instead of a hartid. - Add cf_check as both are indirect call targets now. - Fold in the vintc_ops hook-up, which was a separate patch in v1. It no longer adds vaplic_state_{save,restore}() forwarders: the BUG_ON("unimplemented") path in them was unreachable and has_msi_support() was an MMIO read done on every context switch. - Drop the claim that the not-yet-supported case is guarded by a BUG_ON(); there is no such BUG_ON(). - Update the subject accordingly. --- --- xen/arch/riscv/imsic.c | 23 +++++++++++++++++++++++ xen/arch/riscv/include/asm/imsic.h | 3 +++ xen/arch/riscv/vaplic.c | 7 +++++++ 3 files changed, 33 insertions(+) diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c index ad0a220edac2..3787f270d8e3 100644 --- a/xen/arch/riscv/imsic.c +++ b/xen/arch/riscv/imsic.c @@ -20,6 +20,7 @@ #include #include #include +#include #include #include #include @@ -342,6 +343,28 @@ static int __init imsic_parse_node(const struct dt_dev= ice_node *node, return 0; } =20 +void cf_check imsic_ctxt_switch_from(struct vcpu *v) +{ + struct vimsic_state *imsic_state =3D v->arch.vimsic_state; + unsigned long flags; + + /* + * A vCPU using the s/w IMSIC VS-file (guest_file_id =3D=3D 0) has no = h/w + * VS-file bound to a physical CPU, so there is no location to record. + */ + if ( !vcpu_guest_file_id(v) ) + return; + + write_lock_irqsave(&imsic_state->vsfile_lock, flags); + imsic_state->vsfile_cpu =3D v->processor; + write_unlock_irqrestore(&imsic_state->vsfile_lock, flags); +} + +void cf_check imsic_ctxt_switch_to(struct vcpu *v) +{ + /* Nothing to do */ +} + int cf_check vcpu_imsic_init(struct vcpu *v) { struct vimsic_state *imsic_state; diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/as= m/imsic.h index 93f9e44c7d2c..73129c3c9ea7 100644 --- a/xen/arch/riscv/include/asm/imsic.h +++ b/xen/arch/riscv/include/asm/imsic.h @@ -109,4 +109,7 @@ unsigned int vcpu_guest_file_id(const struct vcpu *v); =20 int vimsic_make_domu_dt_node(struct kernel_info *kinfo, unsigned int *phan= dle); =20 +void imsic_ctxt_switch_from(struct vcpu *v); +void imsic_ctxt_switch_to(struct vcpu *v); + #endif /* ASM_RISCV_IMSIC_H */ diff --git a/xen/arch/riscv/vaplic.c b/xen/arch/riscv/vaplic.c index 8726f7203d6e..6c60fe2baf0c 100644 --- a/xen/arch/riscv/vaplic.c +++ b/xen/arch/riscv/vaplic.c @@ -422,6 +422,13 @@ static const struct mmio_handler_ops vaplic_mmio_ops = =3D { static const struct vintc_ops vintc_ops =3D { .vcpu_init =3D vcpu_imsic_init, .vcpu_deinit =3D vcpu_imsic_deinit, + /* + * MSI delivery is the only supported mode: aplic_init() panics on an + * APLIC without an "msi-parent", so the vAPLIC state to save and rest= ore + * is always the IMSIC one. + */ + .ctxt_switch_from =3D imsic_ctxt_switch_from, + .ctxt_switch_to =3D imsic_ctxt_switch_to, }; =20 int domain_vaplic_init(struct domain *d) --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844145; cv=none; d=zohomail.com; s=zohoarc; b=QV/Bj8LiQ3hPcAe7FLe2NJtMS+Ug8kPYiP1KVKT1w2c7rwKsyhKyCFa///r4ANhXlM3dj9ZujJhzcSApP6V5iW4ktYBpQh8F2FObSDmgRGnoQ+zNURo+4AonuOd7zOQ3G+y5v2YDaenuMyOVDcRoX1zkp1NCQPvWgy+aH3GLXMM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844145; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=2N6LBS4AguM6wfsTAnPZmCDQNz8fb1CS3bfzOT9MwgA=; b=AKIjUYwWrRVTyENfeTldlDZ0/LKC22rl+zCya3kQkjil6oywbZHjPHozo0Zmw71Ft16b6voo3U/r2Cdy6A09Vr39oXdhDzdhNLqKR5ItrN2tmUyWs/nJWVkddczzWAg2DxyaWrTsmFHJUzqsr0CcDDKGS+jl7T09JgKLZXwTF2g= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844145122205.76038972020524; Thu, 27 Aug 2026 08:22:25 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400948.1636682 (Exim 4.92) (envelope-from ) id 1wzbve-0002N5-9r; Thu, 27 Aug 2026 15:22:10 +0000 Received: by outflank-mailman (output) from mailman id 1400948.1636682; Thu, 27 Aug 2026 15:22:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbvd-0002JO-Ug; Thu, 27 Aug 2026 15:22:09 +0000 Received: by outflank-mailman (input) for mailman id 1400948; Thu, 27 Aug 2026 15:22:07 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvb-0001rn-N1 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:07 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvb-003NwR-3C for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:07 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a905614-8faa-0a2a0a5109dd-0a2a450ad1c4-38 for ; Thu, 27 Aug 2026 17:22:07 +0200 Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a90561e-f2d2-0a2a450a0019-d155802fe9a1-3 for ; Thu, 27 Aug 2026 17:22:07 +0200 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-499840a2575so14645945e9.3 for ; Thu, 27 Aug 2026 08:22:06 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:05 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844126; x=1788448926; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=2N6LBS4AguM6wfsTAnPZmCDQNz8fb1CS3bfzOT9MwgA=; b=Qdv18KoVWzS0MZlAwrMNSzfDIjJy8dAvyAPN1R58WTbiyflVRF98V7JYdDLkG0uyJj UfFa1eizQ50t/NpJXC4AC8hVcP7UNgMXYuq4HyZ+yw8wtJWQ+8bpo9H3cOWsYv46roXZ 4xbwsWNphvlOi1awKFXJT5GJmn1T/u5zV9PKyijGMGMVtwLOELgJXRTzekNrWdK6KZQA SSxMQAsnnX38+cLZ6dxKRSlmUwOzRBdWW+7WVIe9DtdCXQCto+UcREYjJbxSumm94tYO cJqv3XRGh2Md5UROBBNrBapfpT/N8PVsVqH1dcStAPBjvzsvubHwQ+jFcH+v0btVgzol AC+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844126; x=1788448926; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=2N6LBS4AguM6wfsTAnPZmCDQNz8fb1CS3bfzOT9MwgA=; b=RttG/UaM2OnR8Jj5TR3kjf/wbMSwA2bhhESQW+W6WyDnRn4w6zp7JGXSUIJiUxw2/9 i8sNXESma0xjdXnm73axshohhpVDjBbfLAWzWsDz44s5dMahfgrwlQrvVrf1QShBNyn1 joG9ee8j7/WHxVvaEeZD38ioCGPZiiMhO2ByiwS3LajUAhWm0/P5c0crxvW9tlfQT3C0 ziUT/WGGzeYOaQjQKEP7y9Oq8uTuh/MsExr6r8Ml1E+s3pndyiKx9zyrrDGAh8zjLTth L0KtXxH5vF22cS7eQxI6npl6sSPz5VeUMWJYoaPTRZcTy9rhKUNM4Y5WYOWfreUg+4I7 yV6g== X-Gm-Message-State: AFuF++ltRGjLl8YGrCzeBMiTDRTjWWgxa/U+RRiXe29cX7bgYkaJ9w5e RUlK/WRvjeR29KFxj+LTtYEN/tmaIB1EsOOtBo2dQUMA2OHcnvs9wB/+UpWm1A== X-Gm-Gg: AR+sD13sfAHIrSJgh7e26WhKpeORHVW3RTz5Y9ulMrWzhNwswCDFPyTR2Eie3dmiOnr OV0VcQqBtc/c+QC+Fs87XUadQMELHG50dUqFdIyemfQtQZb85EgFdAa4kDMnzrDz0D6zM18BZ2q dAgdH6O6zHfwFVbuCllUYMqxn9FmaqXvD9bJK89PWonttmEdBumZnkGEyhqm8J1Tq1iMMJvV/Zn YFCVWGOap7s0K8ydG6f7X0sODvzPPR6jP1yhBiv6BzZejj8p7u85XVP9MlZTqa2ioCWSa+sZ2Jb H83iU4cyMv7QAwnAcPnHsSHGSLX+Ob69gZBEfsiW8amamSh1n/jjQaVUiMaHgV7hmx1KQyeDw1m D9S9VrOVWYwJWXQW9P2uFCE30wiEc23KeGqnonLJkGpD6DNKbp/Jv4u0OPTLWqKQChsUzWpUZsz F76Nn4/b36K9gx8cvaMfpCr0AS3PVXJ0Kp9iYpNw46qF2W9+FvK+qtMC0rAu8bCuXrfr46AxmJI pANs70eRNp5lKlwSXYvQ0qND9sHPNFL X-Received: by 2002:a05:600c:19c9:b0:499:5a50:b022 with SMTP id 5b1f17b1804b1-499dc6f5916mr184759595e9.3.1787844126241; Thu, 27 Aug 2026 08:22:06 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 16/39] xen/riscv: extend exception tables with type and data fields Date: Thu, 27 Aug 2026 17:21:00 +0200 Message-ID: <8aef9dfabe1d485abe4c48fd7499e09dbd8e0c27.1787838835.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-4011c0/1787844127-536D6CFC-5493F82D/10/73395122804 X-purgate-type: spam X-purgate-size: 13807 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844146332158500 Content-Type: text/plain; charset="utf-8" Extend the RISC-V exception table format to include a type and auxiliary data field. The existing format only supports simple fixups. Some use cases require additional context from the fault (e.g. capturing trap information), which cannot be expressed with the current EX_TYPE_FIXUP entries. Introduce a generic ASM_EXTABLE_RAW() helper to describe entries with a handler type and associated data. Reimplement ASM_EXTABLE() in terms of it using EX_TYPE_FIXUP for compatibility. Add EX_TYPE_TRAP_INFO to allow handlers to retrieve trap state (sepc/scause/stval) and pass it to the fixup path. The data field is used to encode which GPR contains a pointer to a struct trap_info. Provide ASM_EXTABLE_TRAP_INFO() as a convenience wrapper for this case. Also add gpr-num.h, providing symbolic GPR numbers for use in assembly and inline asm. This is derived from Linux 6.16 with minor adjustments such as using .irp instead of open-coding the same using a set of .equ. Update the exception handling code to dispatch based on the entry type. Signed-off-by: Oleksii Kurochko --- Changes in v2: - regs_get_gpr(): take a GPR number instead of a byte offset, dropping the multiplication at the call site. A non-multiple-of-8 offset is now unrepresentable. - regs_get_gpr(): ASSERT(num < 32) instead of a range check returning 0, which isn't usable as an error indicator. No num =3D=3D 0 check: reading= x0 is harmless out of context, and a NULL trap_info is caught by the existing BUG_ON() where the dereference happens. - regs_get_gpr(): index the register frame as an array, constify regs and drop the pointless inline. - Anchor the first BUILD_BUG_ON() at offsetof(..., zero) =3D=3D 0 rather t= han at ra, pinning both ends of the x0..x31 range. - Drop MAX_REG_OFFSET; asm/processor.h is no longer touched by this patch. - ex_handler_trap_info(): use regs->sepc and the cause passed down from do_trap() instead of re-reading CSR_SEPC/CSR_SCAUSE; fixup_exception() gains a cause parameter. stval stays a CSR read as do_trap() doesn't read it. - asm/extable.h: revert the .word -> .long change, the extra parens and the stray semicolon after .popsection; use .half for the new type and data fields to match .word. - Make GPR_LIST() the single source of the ABI-name -> register-number mapping, and check struct cpu_user_regs against it at build time, so the two can no longer diverge. - Add the explanatory comment above sturc cpu_user_regs to explain an ordering of x0-x31 registers. --- --- xen/arch/riscv/extable.c | 70 +++++++++++++++++++++++++- xen/arch/riscv/include/asm/extable.h | 64 +++++++++++++++-------- xen/arch/riscv/include/asm/gpr-num.h | 37 ++++++++++++++ xen/arch/riscv/include/asm/processor.h | 14 +++++- xen/arch/riscv/include/asm/traps.h | 6 +++ xen/arch/riscv/traps.c | 2 +- 6 files changed, 169 insertions(+), 24 deletions(-) create mode 100644 xen/arch/riscv/include/asm/gpr-num.h diff --git a/xen/arch/riscv/extable.c b/xen/arch/riscv/extable.c index 5b89c4278c65..6470198d0117 100644 --- a/xen/arch/riscv/extable.c +++ b/xen/arch/riscv/extable.c @@ -6,8 +6,10 @@ #include #include =20 +#include #include #include +#include =20 #define EX_FIELD(ptr, field) ((unsigned long)&(ptr)->field + (ptr)->field) =20 @@ -32,6 +34,12 @@ static void __init cf_check swap_ex(void *a, void *b) =20 x->fixup =3D y->fixup + delta; y->fixup =3D tmp.fixup - delta; + + x->type =3D y->type; + y->type =3D tmp.type; + + x->data =3D y->data; + y->data =3D tmp.data; } =20 static int cf_check cmp_ex(const void *a, const void *b) @@ -59,7 +67,49 @@ static void ex_handler_fixup(const struct exception_tabl= e_entry *ex, regs->sepc =3D ex_fixup(ex); } =20 -bool fixup_exception(struct cpu_user_regs *regs) +#define CHECK_GPR_INDEX(num, name) \ + BUILD_BUG_ON(offsetof(struct cpu_user_regs, name) \ + !=3D (num) * sizeof(unsigned long)); + +static unsigned long regs_get_gpr(const struct cpu_user_regs *regs, + unsigned int num) +{ + /* + * The GPR number -> struct index mapping below relies on x0..x31 being + * laid out at the start of struct cpu_user_regs in architectural orde= r, + * matching the register numbers GPR_LIST() hands to the assembler. + */ + GPR_LIST(CHECK_GPR_INDEX) + + ASSERT(num < 32); + + return ((const unsigned long *)regs)[num]; +} + +#undef CHECK_GPR_INDEX + +static void ex_handler_trap_info(const struct exception_table_entry *ex, + struct cpu_user_regs *regs, + unsigned long cause) +{ + struct trap_info *trap_info =3D + (struct trap_info *)regs_get_gpr(regs, ex->data); + + BUG_ON(!trap_info); + + /* + * Only stval still needs a CSR read: sepc and scause were already + * captured by the trap entry path and do_trap() respectively. Latch + * trap_info->sepc before regs->sepc is pointed at the fixup code. + */ + trap_info->sepc =3D regs->sepc; + trap_info->scause =3D cause; + trap_info->stval =3D csr_read(CSR_STVAL); + + regs->sepc =3D ex_fixup(ex); +} + +bool fixup_exception(struct cpu_user_regs *regs, unsigned long cause) { unsigned long pc =3D regs->sepc; const struct virtual_region *region =3D find_text_region(pc); @@ -77,7 +127,23 @@ bool fixup_exception(struct cpu_user_regs *regs) if ( !ex ) return false; =20 - ex_handler_fixup(ex, regs); + switch ( ex->type ) + { + case EX_TYPE_FIXUP: + ex_handler_fixup(ex, regs); + break; + + case EX_TYPE_TRAP_INFO: + ex_handler_trap_info(ex, regs, cause); + break; + + default: + printk(XENLOG_ERR + "Unsupported exception table entry type %u for pc %#lx\n", + ex->type, pc); + + return false; + } =20 return true; } diff --git a/xen/arch/riscv/include/asm/extable.h b/xen/arch/riscv/include/= asm/extable.h index c0128a91818f..7378f86e7eea 100644 --- a/xen/arch/riscv/include/asm/extable.h +++ b/xen/arch/riscv/include/asm/extable.h @@ -3,17 +3,24 @@ #ifndef ASM__RISCV__ASM_EXTABLE_H #define ASM__RISCV__ASM_EXTABLE_H =20 +#include + +#define EX_TYPE_FIXUP 0 +#define EX_TYPE_TRAP_INFO 1 + #ifdef __ASSEMBLER__ =20 -#define ASM_EXTABLE(insn, fixup) \ - .pushsection .ex_table, "a"; \ - .balign 4; \ - .word (insn) - .; \ - .word (fixup) - .; \ +#define ASM_EXTABLE_RAW(insn, fixup, type, data) \ + .pushsection .ex_table, "a"; \ + .balign 4; \ + .word (insn) - .; \ + .word (fixup) - .; \ + .half (type); \ + .half (data); \ .popsection =20 -.macro asm_extable, insn, fixup - ASM_EXTABLE(\insn, \fixup) +.macro _asm_extable, insn, fixup + ASM_EXTABLE_RAW(\insn, \fixup, EX_TYPE_FIXUP, 0) .endm =20 #else /* __ASSEMBLER__ */ @@ -23,20 +30,36 @@ =20 struct cpu_user_regs; =20 -#define ASM_EXTABLE(insn, fixup) \ - ".pushsection .ex_table, \"a\"\n" \ - ".balign 4\n" \ - ".word (" #insn " - .)\n" \ - ".word (" #fixup " - .)\n" \ +#define ASM_EXTABLE_RAW(insn, fixup, type, data) \ + ".pushsection .ex_table, \"a\"\n" \ + ".balign 4\n" \ + ".word (" insn ") - .\n" \ + ".word (" fixup ") - .\n" \ + ".half (" type ")\n" \ + ".half (" data ")\n" \ ".popsection\n" =20 +#define ASM_EXTABLE(insn, fixup) \ + ASM_EXTABLE_RAW(#insn, #fixup, __stringify(EX_TYPE_FIXUP), "0") + +#define EX_TRAP_INFO_REG(gpr) \ + "(.L_gpr_num_" #gpr ")" + +#define ASM_EXTABLE_TRAP_INFO(insn, fixup, data) \ + DEFINE_ASM_GPR_NUMS \ + ASM_EXTABLE_RAW(#insn, #fixup, __stringify(EX_TYPE_TRAP_INFO), \ + EX_TRAP_INFO_REG(data)) + /* - * The exception table consists of pairs of relative offsets: the first - * is the relative offset to an instruction that is allowed to fault, - * and the second is the relative offset at which the program should - * continue. No general-purpose registers are modified by the exception - * handling mechanism itself, so it is up to the fixup code to handle - * any necessary state cleanup. + * Each exception table entry consists of two relative offsets and a + * handler description: `insn` is the relative offset to an instruction + * that is allowed to fault, `fixup` is the relative offset at which the + * program should continue, `type` selects how the exception is handled + * (EX_TYPE_*), and `data` holds auxiliary information for the handler + * (e.g. for EX_TYPE_TRAP_INFO, the number of the GPR that contains a + * pointer to a struct trap_info). No general-purpose registers are + * modified by the exception handling mechanism itself, so it is up to + * the fixup code to handle any necessary state cleanup. * * The exception table and fixup code live out of line with the main * instruction path. This means when everything is well, we don't even @@ -45,14 +68,15 @@ struct cpu_user_regs; */ struct exception_table_entry { int32_t insn, fixup; + uint16_t type, data; }; =20 extern struct exception_table_entry __start___ex_table[]; extern struct exception_table_entry __stop___ex_table[]; =20 void sort_exception_tables(void); -bool fixup_exception(struct cpu_user_regs *regs); +bool fixup_exception(struct cpu_user_regs *regs, unsigned long cause); =20 -#endif /* __ASSEMBLY__ */ +#endif /* __ASSEMBLER__ */ =20 #endif /* ASM__RISCV__ASM_EXTABLE_H */ diff --git a/xen/arch/riscv/include/asm/gpr-num.h b/xen/arch/riscv/include/= asm/gpr-num.h new file mode 100644 index 000000000000..3b97a72e6c30 --- /dev/null +++ b/xen/arch/riscv/include/asm/gpr-num.h @@ -0,0 +1,37 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +#ifndef RISCV_GPR_NUM_H +#define RISCV_GPR_NUM_H + +/* + * GPRs by ABI name, together with their register number (x0 .. x31). + * + * This is the single source of truth for the mapping: it generates the + * .L_gpr_num_ assembler symbols used to turn a register name emitted + * by the compiler into a register number, and struct cpu_user_regs is + * checked against it at build time (see regs_get_gpr()). Neither list can + * therefore be changed without the other. + */ +#define GPR_LIST(x) \ + x(0, zero) x(1, ra) x(2, sp) x(3, gp) \ + x(4, tp) x(5, t0) x(6, t1) x(7, t2) \ + x(8, s0) x(9, s1) x(10, a0) x(11, a1) \ + x(12, a2) x(13, a3) x(14, a4) x(15, a5) \ + x(16, a6) x(17, a7) x(18, s2) x(19, s3) \ + x(20, s4) x(21, s5) x(22, s6) x(23, s7) \ + x(24, s8) x(25, s9) x(26, s10) x(27, s11) \ + x(28, t3) x(29, t4) x(30, t5) x(31, t6) + +#ifdef __ASSEMBLER__ + +#define GPR_NUM_EQU(num, name) .equ .L_gpr_num_##name, num; +GPR_LIST(GPR_NUM_EQU) +#undef GPR_NUM_EQU + +#else /* __ASSEMBLER__ */ + +#define GPR_NUM_EQU(num, name) ".equ .L_gpr_num_" #name ", " #num "\n" +#define DEFINE_ASM_GPR_NUMS GPR_LIST(GPR_NUM_EQU) + +#endif /* __ASSEMBLER__ */ + +#endif /* RISCV_GPR_NUM_H */ diff --git a/xen/arch/riscv/include/asm/processor.h b/xen/arch/riscv/includ= e/asm/processor.h index b1745c107100..e7b0f2321a0e 100644 --- a/xen/arch/riscv/include/asm/processor.h +++ b/xen/arch/riscv/include/asm/processor.h @@ -12,7 +12,19 @@ =20 #ifndef __ASSEMBLER__ =20 -/* On stack VCPU state */ +/* + * On stack VCPU state. + * + * x0..x31 must remain at the start of this structure, in architectural + * register-number order: code which resolves a register number to its sav= ed + * value indexes this structure directly (instruction emulation via + * REG_PTR() from asm/riscv_encoding.h, exception table fixups via + * regs_get_gpr()). ->zero therefore has to stay at offset 0 and must alwa= ys + * read as 0, since it supplies the value of x0 when x0 is used as a source + * operand. The layout is checked against GPR_LIST() at build time; see + * regs_get_gpr() in extable.c. Do not reorder these fields or insert + * anything between them. + */ struct cpu_user_regs { unsigned long zero; diff --git a/xen/arch/riscv/include/asm/traps.h b/xen/arch/riscv/include/as= m/traps.h index 21fa3c3259b3..8d4ab664bca9 100644 --- a/xen/arch/riscv/include/asm/traps.h +++ b/xen/arch/riscv/include/asm/traps.h @@ -7,6 +7,12 @@ =20 #ifndef __ASSEMBLER__ =20 +struct trap_info { + register_t sepc; + register_t scause; + register_t stval; +}; + void do_trap(struct cpu_user_regs *cpu_regs); void handle_trap(void); void trap_init(void); diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c index 093d81e2d803..11a6fa1bc942 100644 --- a/xen/arch/riscv/traps.c +++ b/xen/arch/riscv/traps.c @@ -217,7 +217,7 @@ void do_trap(struct cpu_user_regs *cpu_regs) break; } =20 - if ( fixup_exception(cpu_regs) ) + if ( fixup_exception(cpu_regs, cause) ) break; =20 fallthrough; --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844156; cv=none; d=zohomail.com; s=zohoarc; b=ghdyeT6eahwIL7jdyp/iHDbIlNQXxqTPptAVKjiFkybrUbuZpgqP56gU2bvALhXaEFXaKSt3jguyjIpYIvcKf7AmNdvR+KkItJBonXfvTEQ7olsSXJrpWmTRhNavi81rjB1XeWTUHSjhi42NqZ+PY8CWXKT+omkve1XmUx3CoLc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844156; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=jpyIt3QNCfxzvUHqjTjX85Q2soB8SmL27WaWTeD9J3I=; b=Tc1r7pnq80B3y52WzEP5dfwTdLnY5EgfxrsyrchTiHsd3E44hmLnqtYA1KXvHHC7XnarYOQjFb7s44MEZJzGrS3IHPxmWViy/MVASgFPExoIXr3S00JZjG1PJ4dF3SJwrdHmJdEeZJ7DujGdadFRNX6QDDqjMIadpB0TulqnI9A= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 17878441560424.614678693628321; Thu, 27 Aug 2026 08:22:36 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400950.1636686 (Exim 4.92) (envelope-from ) id 1wzbvf-0002Wq-3P; Thu, 27 Aug 2026 15:22:11 +0000 Received: by outflank-mailman (output) from mailman id 1400950.1636686; Thu, 27 Aug 2026 15:22:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbve-0002UM-R6; Thu, 27 Aug 2026 15:22:10 +0000 Received: by outflank-mailman (input) for mailman id 1400950; Thu, 27 Aug 2026 15:22:09 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvc-000227-R1 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:08 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvc-00C7Ax-7Z for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:08 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a90561c-e002-0a2a0a5209dd-0a2a45079110-14 for ; Thu, 27 Aug 2026 17:22:08 +0200 Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a905620-b4ea-0a2a45070019-d155802fed7f-3 for ; Thu, 27 Aug 2026 17:22:08 +0200 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-4998b5a63e2so21333645e9.1 for ; Thu, 27 Aug 2026 08:22:08 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:07 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844128; x=1788448928; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=jpyIt3QNCfxzvUHqjTjX85Q2soB8SmL27WaWTeD9J3I=; b=EAMjo5s4Z0j45k/zOLB5q7TCGmlvLElcloxvzCiWOj0aGBbcnCXKZiUJNyyi2pHA+S 6NS7n52NAUNzvWJVnf7DzS6xUTEk/MG3/gVz5/fMtoRqfvvHk99dlyscVJNH4/thxXLe IT8P0cJh2OBbzkcc2hPRFERk9Rca3YnAIbH1wJlR2Vb5no+mlDGXpDZINndWXPPIyTWP zlepNmpW3PczqF2zF86ceOcYTAGeglhV2JwChtN+Hdl7/QfqIljc1J6zolNApZ6FV42q UV8cOSByVONByyoG+dP0uSz4o3G91zpeczOBkjnNcp7gb1ApfSZziavwxQ+e2aNm2bzA vQpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844128; x=1788448928; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=jpyIt3QNCfxzvUHqjTjX85Q2soB8SmL27WaWTeD9J3I=; b=TU15MM8AWcERv/LTLmALhB5fhkTM9GM5piQruVn1hM724tQz/l2wdjholy+CPm13WB IX60Mc0Jx4gEY24zLUj2SND2CSKLv1+zPL2nsq4qNiGgPuvgTtmtZ7G7EoJKDjFCYhN9 JBGweX+ewF28Eu8frJv6dzaKr4BVAsbOJroiSn8bMC+x5KbXSf2QxNDqJkQZM+KdZV7W xlnaIVe37PNTzs9tQ2CA8yfDuIo+9rkww0JN1jhoJbwfUq+I7t/AiH9xmCHI9cWRoh0a HudTn6m7oCzDSxo8phGlWFPcJN0mDDn+O/2XUX4AZ9SrP0HrY2fFW2Kx7d/qazMvCowa TaRA== X-Gm-Message-State: AFuF++nD3ryzDuH7MYl0ume5Zx1XNU501v6MMlqsr0xVTFV9s+V7dXFW r9E3M6ZqGyvvtHbc7+IkjWOyRvCdDoV0RtbC0axO5wZtUjDs2AGfKZIjnCuIzw== X-Gm-Gg: AR+sD12FrJqR31kHC7hAS563wEsjXgFs7Vumo1zQnsx61iz8CpmVa9DdlWV3ArFKhcw jB8nUHCk7zmuDeQGGCL8aMnGGmBXg06M42tnKutcF/QG6Ma1H5up9b9E784MvvTw1FMyW3LdKBG x3GovfbrotptMCF3hXHNqdS191eDY8U9ffomQMSYDJqtSMCWm63qIGg4WfXwYZFaw8/7gr9HEmy gLV9EMUY38YzYFpzpe8SfEs4TwqUYCc2M52tasMdRhbxtKO0Uwl0wcHsGbNV8pu+6IZFOkMPc8D UODjlStDXAH099XZwIIhzJrmDbkLDxZR2BH3g1mLJxdEdXAe9pLWhCKya5zmMv+32Pna98e4SRg 7ICGTflEsoI76XrXbLIwf6u89pUewRxXewKTrw//JOwp/5/LSjKyBGRcaRxSsN/NfKh5SlwBz8m 1k3v8MaMngG2y9v2ZfevO3GexvM95lxZJknNrTLtlBXKTxHx6Cl3bUA9Vjj+5W/dlHoE8xrqwR5 RDAgxAg+MDF9/4SmqGjgMX1JgCfFS5V X-Received: by 2002:a05:600c:19c6:b0:499:900c:9c69 with SMTP id 5b1f17b1804b1-499dc7252fcmr185578725e9.9.1787844127516; Thu, 27 Aug 2026 08:22:07 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 17/39] xen/riscv: decouple INSN_PSEUDO_VS_* from the hypervisor's XLEN Date: Thu, 27 Aug 2026 17:21:01 +0200 Message-ID: <2a69992aa02ff114237ec27204cfac0f8278b1d6.1787838835.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-ef75cf/1787844128-354C3AE4-75A4F469/10/73395122804 X-purgate-type: spam X-purgate-size: 3046 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844156317158500 Content-Type: text/plain; charset="utf-8" htinst reports a pseudoinstruction when a guest page fault is taken on an implicit memory access done for VS-stage address translation. Four such values are defined, differing in the access type (read or write) and in the access width: 4 bytes (0x2000/0x2020) or 8 bytes (0x3000/0x3020). That width is the width of a VS-stage PTE, i.e. it follows the guest's paging mode (4 bytes for Sv32, 8 bytes for Sv39 and wider) and has nothing to do with the XLEN Xen itself is built for. Selecting just one pair with where a guest running with VSXL=3D32 and Sv32 in vsatp produces the 4-byte forms. Such an htinst would not be recognized as a pseudoinstruction and the fault would be mistaken for an ordinary MMIO trap: Xen would fetch and decode whatever instruction sepc happens to point at (unrelated to the access which faulted) and emulate it against a guest physical address derived from htval, which for an implicit access holds the address of a VS-stage PTE rather than of any access the guest performed. Define all four values unconditionally instead, named after the access width they encode rather than after the build's XLEN. On RV32 the 8-byte forms simply never occur, so recognizing them costs nothing. Dropping the ladder loses no build-time coverage: a build for an XLEN other than 32 or 64 already fails on the equivalent ladders in asm/asm.h and asm/config.h, so no replacement #error is needed here. Adding one keyed on CONFIG_RISCV_* would in any case re-introduce exactly the conflation this patch removes. This diverges from the imported version of riscv_encoding.h. No functional change: the values have no user yet. Signed-off-by: Oleksii Kurochko --- Changes in v2: - New patch. --- --- xen/arch/riscv/include/asm/riscv_encoding.h | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/xen/arch/riscv/include/asm/riscv_encoding.h b/xen/arch/riscv/i= nclude/asm/riscv_encoding.h index c63e5e304691..2d2e7e11b3ef 100644 --- a/xen/arch/riscv/include/asm/riscv_encoding.h +++ b/xen/arch/riscv/include/asm/riscv_encoding.h @@ -839,25 +839,17 @@ #define INSN_MASK_FENCE_TSO 0xffffffff #define INSN_MATCH_FENCE_TSO 0x8330000f =20 -#if __riscv_xlen =3D=3D 64 - /* 64-bit read for VS-stage address translation (RV64) */ -#define INSN_PSEUDO_VS_LOAD 0x00003000 +#define INSN_PSEUDO_VS_LOAD64 0x00003000 =20 /* 64-bit write for VS-stage address translation (RV64) */ -#define INSN_PSEUDO_VS_STORE 0x00003020 - -#elif __riscv_xlen =3D=3D 32 +#define INSN_PSEUDO_VS_STORE64 0x00003020 =20 /* 32-bit read for VS-stage address translation (RV32) */ -#define INSN_PSEUDO_VS_LOAD 0x00002000 +#define INSN_PSEUDO_VS_LOAD32 0x00002000 =20 /* 32-bit write for VS-stage address translation (RV32) */ -#define INSN_PSEUDO_VS_STORE 0x00002020 - -#else -#error "Unexpected __riscv_xlen" -#endif +#define INSN_PSEUDO_VS_STORE32 0x00002020 =20 #define INSN_16BIT_MASK 0x3 #define INSN_32BIT_MASK 0x1c --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844152; cv=none; d=zohomail.com; s=zohoarc; b=nNK+K/DsuFkTRLMtKJJQ9RsHzCS8n063NEg6QJYoBCQ85RDUPiKI+wA0li0a5cKoxCfCVbMTWdRNwD91fMmqKOZ2hvH+irqcLT4DTCAYipic2YCGSxTCy4eU06G7GK3am/rm4IxikHKG3KrOUEMAJJZQqLdQPQghFi5Xv4Cb+XY= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844152; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=O68oZFCfXHfk/QZ3xStOhptGKFjcOPvB2fsPLA0mazI=; b=A3wjGTixrZ2f8sOEUzM6FQg7nj0U9qH7FNuCGUjMJya/vEr9Zd4WEnBYRSpPCOO1q/exnYTMzNyyyWfvznWgtytdi8F33FpKuimMRKcYPZ5frvZgDqwZmrAkkWmcyi/FWByri8+xg63ghvffVjJlrDGv2j5k3KHt5hmo73fxquA= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844152876679.1830241870753; Thu, 27 Aug 2026 08:22:32 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400953.1636694 (Exim 4.92) (envelope-from ) id 1wzbvg-0002q8-KG; Thu, 27 Aug 2026 15:22:12 +0000 Received: by outflank-mailman (output) from mailman id 1400953.1636694; Thu, 27 Aug 2026 15:22:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbvg-0002o6-6F; Thu, 27 Aug 2026 15:22:12 +0000 Received: by outflank-mailman (input) for mailman id 1400953; Thu, 27 Aug 2026 15:22:10 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbve-0002P7-GN for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:10 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvd-009kzH-TD for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:09 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a905616-2eae-0a2a0a5409dd-0a2a4501a8e6-32 for ; Thu, 27 Aug 2026 17:22:09 +0200 Received: from [209.85.128.50] (helo=mail-wm1-f50.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a905621-5984-0a2a45010019-d1558032e01e-3 for ; Thu, 27 Aug 2026 17:22:09 +0200 Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-49b8e527d63so6385605e9.2 for ; Thu, 27 Aug 2026 08:22:09 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:08 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844129; x=1788448929; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=O68oZFCfXHfk/QZ3xStOhptGKFjcOPvB2fsPLA0mazI=; b=hdXrQLwyNYMXTPP5Z0v9i6+NYAN3htktxEQAB7pm+O8PwhRO482V+7X2B61WYCckSX vsVql0dujLJzj95BVU7u7qUBfg0t3gCMS7JTQFDfwdV0c0mDshjbVf3v8NrcmGEx4ULb +zGNQh2QNi24slHhLpfulzSWniaNKacfc/PylvSofedA16cwLUbvzu8RlYFC+owoEbCz 1DiD1jqyayJG9JbGPbiPA7AMPO19r3QB80LVZeN7cSp0LIygks/nGZspQ+PZt2v5MeJ9 Q9hyNlimlm9jWmCKdRFGiz6/ja7yA/Zm05jrfK+PlO1aScJcJKGtlPC8iUAlAEXZo6Fw hgtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844129; x=1788448929; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=O68oZFCfXHfk/QZ3xStOhptGKFjcOPvB2fsPLA0mazI=; b=XP25m6tTJt7xIefaFdEHOUD3nJTZeU2WLCy/dZZa4rvG4c0TedeggB7DjApda9NOqh L4J269Szm+unZWTM/AGlwOYj+q0GbmAZnH8xD/iWe/pZF/rSH/JRq50ECk5e92EN/wfH Kmwy4UJFanftCYs/dj11Ai6f8KI3agPhQS6THiPb9wP6sex2WdrfSeMEmfpw6NoeQ0F5 B8XtbNUeQsXkWkg8TEfDIoiGCZ+X2ovDlL9zDxy5CT+oRrX5XjrKz/sLWBIbL7Z/K/uG jHbQJhxSEtFsIenXQRkndETcObNza7YQzdEhz2sLN3Ap6gn9roNkaGkNR8mK0aqrnwzf 3HOw== X-Gm-Message-State: AFuF++ls5AMwTjKa7rrsy9PUUr1fenVqklB6rZPwiuNQ1WFTz780jq0a 8ZU8kj0Cf2rH+SwIamdDF1/LkUQ2odmvilf00wIx+jgn42pzcMmODWibQdy5Aw== X-Gm-Gg: AR+sD129jvJU05uMf4Xr5DoDCD+e1HvTU6N5T/5C0saX05nr6HrGTm6lN0Sc2A9dETf uDn6huMRBk9ka7gtIhvWlxMSSWkDpO0ueny4qjNWfrYY6ZAKLRqgjvj4FVn+ZO5rsaQcWcLvDGU tc3vZXdWHQYhlqc0so4sHnVy1CYB3mM1Vdr92ZSs4u5yftZ47m4culwk2N47oyC9UXAJfSxME2S wWAgmrMthIqeqpdDtrRoN69C52bzWCPqqYIhJ/vTAY23h6b1+CrMCPWORIsquMK7UVwy94Sposd v9vkDpvySjHTtvhZDi1CfXY/g7J25piid9djKpMM/vmeqVfj2fK8dkEJCnNJUssXz7uwiMZUvrT 60RYCsrGOkmCwmkCeg2kcF2yeKubeIHeAuHceiVuvX/b3tQ1zQWmQJlNl2+xbF2zntSMzFNoPON Pf/urTYN6lDlKhznr1MLqd0SBSTZeQDiuUgYtuqUQZE8g1nkGM+aaKto56deri8LvAmET6LQJVP jruQU4XUR5YdWIXO6TLczV8ptba2xpI X-Received: by 2002:a05:600c:698c:b0:493:cefc:d113 with SMTP id 5b1f17b1804b1-499dc6f5dcdmr224736685e9.5.1787844129021; Thu, 27 Aug 2026 08:22:09 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 18/39] xen/riscv: add guest page fault handling stub Date: Thu, 27 Aug 2026 17:21:02 +0200 Message-ID: <42e37df518f1eda9579264b4bae9db3521e1042a.1787838835.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d62444/1787844129-C4359757-CAD6905E/10/73395122804 X-purgate-type: spam X-purgate-size: 12235 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844154351158500 Content-Type: text/plain; charset="utf-8" Add a handler for guest page faults and hook it into the trap path, providing the trap-side entry point which will later feed the MMIO dispatch. This will be used, for example, to trap accesses to APLIC registers so that a guest can initialize and drive an emulated interrupt controller. Two of the situations handled here are already decided, as neither can ever be turned into an emulated access: - A fault reported with a pseudoinstruction in htinst was taken on an implicit access made for VS-stage address translation, so htval holds the address of a VS-stage PTE rather than of anything the guest asked for, and the guest physical address behind the original access is not known. This is orthogonal to the cause and can accompany any of the three, which is why it is checked first. scause keeps reporting the type of the original access, and on bare hardware a PTE which cannot be read raises an access fault of exactly that type, so reflect one back to the guest. - A fetch fault means the guest tried to execute from a guest physical address which is unmapped or which G-stage does not allow to be executed. On bare hardware a fetch from physical memory which does not exist, or which may not be executed, raises an instruction access fault, so reflect one back too. Explicit loads and stores are where MMIO emulation will hook in. Neither of the two paths above consults the p2m first, and neither will the MMIO one: RISC-V has no populate-on-demand, no paging and no mem_access, so every guest mapping is established eagerly and a G-stage fault never denotes a mapping Xen could install to let the faulting access complete. Both of the helpers this leans on, resolve_faulting_gpa() and trap_redirect(), are BUG_ON() placeholders for now, so each of the three causes currently takes the host down rather than the domain. That is no worse than before this patch, where the same causes fell through to do_unexpected_trap() and die(). Implementing the helpers is left to later patches. Signed-off-by: Oleksii Kurochko --- Changes in v2: - Introduce struct guest_fault. - Change the prototypes of emulate_{load,store}() to take a non-const struct guest_fault, as emulation has to write the destination register and advance sepc. - Add handling of pseudoinstructions before the call of emulate_{load,store}. - Rename get_fault_gpa to resolve_faulting_gpa and change its prototype to take struct guest_fault. - Add handling of CAUSE_FETCH_GUEST_PAGE_FAULT now. - Document why the p2m is not consulted before a fault is injected, and add a BUILD_BUG_ON() on CONFIG_VM_EVENT to catch that assumption breaking. - Print the fault cause in the domain_crash() message rather than deriving an access type string which cannot cover every case. - Move code to introduced emulate.c instead of having it in traps.c --- --- xen/arch/riscv/Makefile | 1 + xen/arch/riscv/emulate.c | 179 +++++++++++++++++++++++++++ xen/arch/riscv/include/asm/emulate.h | 10 ++ xen/arch/riscv/include/asm/traps.h | 3 + xen/arch/riscv/traps.c | 23 +++- 5 files changed, 215 insertions(+), 1 deletion(-) create mode 100644 xen/arch/riscv/emulate.c create mode 100644 xen/arch/riscv/include/asm/emulate.h diff --git a/xen/arch/riscv/Makefile b/xen/arch/riscv/Makefile index ce6410a299a4..4a021ee9eb70 100644 --- a/xen/arch/riscv/Makefile +++ b/xen/arch/riscv/Makefile @@ -6,6 +6,7 @@ obj-y +=3D domain.o obj-y +=3D domain-build.init.o obj-$(CONFIG_DOM0LESS_BOOT) +=3D dom0less-build.init.o obj-$(CONFIG_EARLY_PRINTK) +=3D early_printk.o +obj-y +=3D emulate.o obj-y +=3D entry.o obj-y +=3D extable.o obj-y +=3D guestcopy.o diff --git a/xen/arch/riscv/emulate.c b/xen/arch/riscv/emulate.c new file mode 100644 index 000000000000..f9da0751049c --- /dev/null +++ b/xen/arch/riscv/emulate.c @@ -0,0 +1,179 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ + +/* + * RISC-V instruction emulation for trapped guest accesses + */ + +#include +#include +#include +#include + +#include +#include +#include +#include +#include + +/* + * The hardware-reported details of a guest page fault, gathered once by + * handle_guest_page_fault() and passed down to the emulation of the fault= ed + * access. + */ +struct guest_fault { + /* The guest register state as saved on entry to do_trap(). */ + struct cpu_user_regs *regs; + /* scause: a fetch, a load or a store/AMO guest page fault. */ + unsigned long cause; + /* + * htinst: the trapped instruction in its transformed form, or one of = the + * special values (zero, or a pseudoinstruction). + */ + unsigned long htinst; + /* htval: as written by hardware; see resolve_faulting_gpa(). */ + unsigned long htval; + /* stval: the guest virtual address of the faulting access. */ + unsigned long stval; + /* The faulting guest physical address, filled by resolve_faulting_gpa= (). */ + paddr_t gpa; +}; + +/* + * Is @htinst one of the pseudoinstructions reported for a guest page fault + * taken on an implicit memory access done for VS-stage address translatio= n? + * + * All four values are recognized regardless of the hypervisor's XLEN: the + * width they encode is that of a VS-stage PTE, i.e. it follows the guest's + * paging mode (4 bytes for Sv32, 8 otherwise). On RV32 the 64-bit forms + * simply never occur. + */ +static bool htinst_is_pseudo(unsigned long htinst) +{ + switch ( htinst ) + { + case INSN_PSEUDO_VS_LOAD32: + case INSN_PSEUDO_VS_STORE32: + case INSN_PSEUDO_VS_LOAD64: + case INSN_PSEUDO_VS_STORE64: + return true; + + default: + return false; + } +} + +/* Reconstruct the guest physical address of the access which faulted. */ +static void resolve_faulting_gpa(struct guest_fault *gf) +{ + BUG_ON("unimplemented"); +} + +static int emulate_load(const struct guest_fault *gf) +{ + return -EOPNOTSUPP; +} + +static int emulate_store(struct guest_fault *gf) +{ + return -EOPNOTSUPP; +} + +static void inject_access_fault(const struct guest_fault *gf) +{ + struct trap_info utrap =3D {}; + + switch ( gf->cause ) + { + case CAUSE_FETCH_GUEST_PAGE_FAULT: + utrap.scause =3D CAUSE_FETCH_ACCESS; + break; + + case CAUSE_LOAD_GUEST_PAGE_FAULT: + utrap.scause =3D CAUSE_LOAD_ACCESS; + break; + + case CAUSE_STORE_GUEST_PAGE_FAULT: + utrap.scause =3D CAUSE_STORE_ACCESS; + break; + + default: + domain_crash(current->domain, "Impossible cause (%#lx) in %s?\n", + gf->cause, __func__); + return; + } + + utrap.sepc =3D gf->regs->sepc; + utrap.stval =3D gf->stval; + + trap_redirect(&utrap); +} + +void handle_guest_page_fault(struct cpu_user_regs *regs, unsigned long cau= se) +{ + struct guest_fault gf =3D { + .regs =3D regs, + .cause =3D cause, + .htinst =3D csr_read(CSR_HTINST), + .htval =3D csr_read(CSR_HTVAL), + .stval =3D csr_read(CSR_STVAL), + .gpa =3D INVALID_PADDR, + }; + int rc; + + /* + * A guest-page fault may arise due to an implicit memory access during + * first-stage (VS-stage) address translation, in which case a guest + * physical address written to htval is that of the implicit memory + * access that faulted - for example, the address of a VS-level page + * table entry that could not be read. (The guest physical address + * corresponding to the original virtual address is unknown when + * VS-stage translation fails to complete) + * + * In such cases htinst reports one of the pseudoinstructions recogniz= ed + * by htinst_is_pseudo(), and the fault requires separate handling (si= nce + * G-stage translation failed on an unpopulated/unmapped guest physical + * address during a hardware page-table walk). To match bare hardware + * behavior, we must inject an access fault of the ORIGINAL access type + * (Instruction, Load, or Store/AMO) that initiated the address + * translation. + */ + if ( htinst_is_pseudo(gf.htinst) ) + { + inject_access_fault(&gf); + + return; + } + + resolve_faulting_gpa(&gf); + + switch ( cause ) + { + case CAUSE_LOAD_GUEST_PAGE_FAULT: + rc =3D emulate_load(&gf); + break; + + case CAUSE_STORE_GUEST_PAGE_FAULT: + rc =3D emulate_store(&gf); + break; + + case CAUSE_FETCH_GUEST_PAGE_FAULT: + /* + * Guest is trying to reach unmapped/unpopulated or G-stage PTE do= esn't + * allow execution (X=3D0). Generate fetch fault in this case. + */ + inject_access_fault(&gf); + rc =3D 0; + break; + + default: + rc =3D -EOPNOTSUPP; + ASSERT_UNREACHABLE(); + break; + } + + if ( rc ) + domain_crash(current->domain, + "%s: unable to handle guest page fault (cause=3D%#lx)= at " + "gpa %#"PRIpaddr"\n", + __func__, cause, gf.gpa); +} diff --git a/xen/arch/riscv/include/asm/emulate.h b/xen/arch/riscv/include/= asm/emulate.h new file mode 100644 index 000000000000..59e69ca6794c --- /dev/null +++ b/xen/arch/riscv/include/asm/emulate.h @@ -0,0 +1,10 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ + +#ifndef RISCV_EMULATE_H +#define RISCV_EMULATE_H + +struct cpu_user_regs; + +void handle_guest_page_fault(struct cpu_user_regs *regs, unsigned long cau= se); + +#endif /* RISCV_EMULATE_H */ diff --git a/xen/arch/riscv/include/asm/traps.h b/xen/arch/riscv/include/as= m/traps.h index 8d4ab664bca9..38c6423742e0 100644 --- a/xen/arch/riscv/include/asm/traps.h +++ b/xen/arch/riscv/include/asm/traps.h @@ -17,6 +17,9 @@ void do_trap(struct cpu_user_regs *cpu_regs); void handle_trap(void); void trap_init(void); =20 +/* Reflect @trap back to the guest, i.e. enter its VS-mode trap handler. */ +void trap_redirect(const struct trap_info *trap); + #endif /* __ASSEMBLER__ */ =20 #endif /* ASM__RISCV__TRAPS_H */ diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c index 11a6fa1bc942..9cd37d943be1 100644 --- a/xen/arch/riscv/traps.c +++ b/xen/arch/riscv/traps.c @@ -14,6 +14,7 @@ =20 #include #include +#include #include #include #include @@ -193,6 +194,7 @@ void do_trap(struct cpu_user_regs *cpu_regs) { register_t pc =3D cpu_regs->sepc; unsigned long cause =3D csr_read(CSR_SCAUSE); + bool from_guest =3D cpu_regs->hstatus & HSTATUS_SPV; =20 switch ( cause ) { @@ -203,6 +205,19 @@ void do_trap(struct cpu_user_regs *cpu_regs) vsbi_handle_ecall(cpu_regs); break; =20 + case CAUSE_FETCH_GUEST_PAGE_FAULT: + case CAUSE_LOAD_GUEST_PAGE_FAULT: + case CAUSE_STORE_GUEST_PAGE_FAULT: + /* + * A guest page fault taken in Xen context comes from an hlv/hlvx + * access made on a vCPU's behalf and is dealt with by the + * fixup_exception() above, so only a guest can get here. + */ + BUG_ON(!from_guest); + + handle_guest_page_fault(cpu_regs, cause); + break; + case CAUSE_ILLEGAL_INSTRUCTION: if ( do_bug_frame(cpu_regs, pc) >=3D 0 ) { @@ -251,7 +266,7 @@ void do_trap(struct cpu_user_regs *cpu_regs) break; } =20 - if ( cpu_regs->hstatus & HSTATUS_SPV ) + if ( from_guest ) check_for_pcpu_work(); } =20 @@ -275,3 +290,9 @@ enum mc_disposition arch_do_multicall_call(struct mc_st= ate *state) BUG_ON("unimplemented"); return mc_continue; } + +/* Redirect trap to Guest. */ +void trap_redirect(const struct trap_info *trap) +{ + BUG_ON("unimplemented"); +} --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844159; cv=none; d=zohomail.com; s=zohoarc; b=l1r99rCwebNBEkKDnWzFGyYob/oJl+t9CWrf9NhYLItMpAhkOvPpme7cEbpU9cHfIpYKOTmKcWqNhsD1/5jN56JehTr0FDiny4M1JB4mKZHFWICcxSzh72LKFHmX4ntUD3VT5nlVzGhpb34Jc0KNhjsv8g8tXA+wXbvOCl85PvI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844159; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=hXEgdEjyT/o0vCdnbINLyc8KPk5JZJDfyvEdU7D5Poc=; b=N7c7hiFNrl4akxCUub+6/prLoLkzY3fYmmNJ8xJkshmI50TA7szJYgF4C5NitIg5xJG+QZOrOGmiktxxYLX7+VMk/lkQsVz1ogfiil8Kbn02spM8m61T+FBM/P6aNAenVaJG661j52pQ24BftqZPlvk6vJNMnHsMFWjsfnbbHJ4= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844159408957.8728771143709; Thu, 27 Aug 2026 08:22:39 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400957.1636703 (Exim 4.92) (envelope-from ) id 1wzbvi-0003Bk-D2; Thu, 27 Aug 2026 15:22:14 +0000 Received: by outflank-mailman (output) from mailman id 1400957.1636703; Thu, 27 Aug 2026 15:22:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbvh-0003Ag-VB; Thu, 27 Aug 2026 15:22:13 +0000 Received: by outflank-mailman (input) for mailman id 1400957; Thu, 27 Aug 2026 15:22:12 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvg-0002lu-4b for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:12 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvf-009kzH-HN for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:11 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a90561e-2eae-0a2a0a5409dd-0a2a4502cbb6-14 for ; Thu, 27 Aug 2026 17:22:11 +0200 Received: from [209.85.221.48] (helo=mail-wr1-f48.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a905623-6ca4-0a2a45020019-d155dd30cc50-3 for ; Thu, 27 Aug 2026 17:22:11 +0200 Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-47f633e6058so1725209f8f.0 for ; Thu, 27 Aug 2026 08:22:11 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:10 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844131; x=1788448931; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=hXEgdEjyT/o0vCdnbINLyc8KPk5JZJDfyvEdU7D5Poc=; b=BxEoe+UMB0VfJSkdycFds8Wq3UrmN4n63H7Tw+6S6yzRnLnf2QzGBjnJfp1PSNw8DI 1eiMNg4zlE63UI8C+nuXTNQXdoSJTyINPJ5ShGqbENnozrMHycRwgj59EX9mjXh+YBr9 8dLrNoBsqy9RbXtteoimzhWSsZRhbusLwQc6HOY8kWxXmc5aZDTPBs+I+gEs6kYING/x 5/jbSwvdgQaYTOdME4r8vvYJHb3HuuNMbYXuI2NOt/G3hou8/F8RudLxEAHot46oBiAz OeKJrbbAyUnY24EGndtfSVFciMfrDKZ88n/XXnQ+NkWeK2wHFpFoGRMbOKMRa3RcZeaM 1qCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844131; x=1788448931; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=hXEgdEjyT/o0vCdnbINLyc8KPk5JZJDfyvEdU7D5Poc=; b=d5owGGnuIlxYEjAjUw24ZK6Q/WNA9ecdaetIyEhNCBEN4iRcU+EClCxRdAD5smWxyH Wjp8nKRGJ6OvDIBY0lnNb7FhKBWIxAjXOUKMX/7cyACtKi8F9hn6/AAVZp1W/nxgG8sG 6AjdByWvpU2ZkOMmdKIb2vPhtagenoS7dGXNN/vavWjm64J9PJ9UWiCChSduOZREah1W xXIOq5yss7zTgubTLjwhLagsarym2MagF6sfePknoF9MJw23UjwkO7ciVvs7xV4BhQyp knKuWHSwD6QHAYdvfGSZoTXwFd5fuQk6GnyY++4ZXLsFO8wY17HEAuCypYWUnEDoigMh UtDQ== X-Gm-Message-State: AFuF++lEU1zZ+32Qno9q+sy3OKY3NIoXsgtGVumS0fkM7r3FJVgLhTzM k2anMxsxP2bjUxYiIZsBGRZ79ijDfLZ7C4MnMYbSbVVd0epRuXobTkkZDBHJUQ== X-Gm-Gg: AR+sD13Up3sTGJ5BCBbeKOrdNamreOlK6Km8mdcz/RDB7YW1ISwqvtAbVPTZ9nB3UIZ XD5WRfiJpM1M/fNyjTlNNk6J1NJV4LwiYnWjz0ldZ3nJJgds3/TlWpHhjoDpksfv0CIUTgH2Jq7 3rpEPA/IdDfJctGXpMaYnnABRM30An59HWdbMij8E4o7J42YyTGbVCwTFwvfH/5QQ088Qs+urGb NH6Lv8Pb+g4sZreFzRk3bQwUOVDR2ar8sBqr6Si6yXz9pGJi/kANJdMV+YxiMPmoqGlGWQqhX3Z BfLnMuOfMCTZe071sEuHPV2oTZdqHeWUziNuowNQW/ArgRKnX0j5ILejQ7jxDAlBOgxWEeN2HLV vLw2nA5C1yUsiLRQqCqpNhrwsG3MY3OdVqZTo90eKmpxr62n6l2DwKOvailIMWRm2YF6kaM6krN DngNvoicRW20W2neuO0fQ+8IXRyp9pGdaV4yF9zui/Ih5rGck+evYMAgAr8kk4D1+fOEar/7FSH wvtL26qiSNCm6XkCdD/EQ6eBi/NUoLbhw== X-Received: by 2002:a05:600c:3b8b:b0:499:7a19:408b with SMTP id 5b1f17b1804b1-499dc722993mr205648655e9.11.1787844130383; Thu, 27 Aug 2026 08:22:10 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 19/39] xen/riscv: implement trap redirection to a guest Date: Thu, 27 Aug 2026 17:21:03 +0200 Message-ID: <583b0a190bad7121eae9bc99bd1e13dc1743efe4.1787838835.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-720697/1787844131-309C32AC-D8EDFA32/10/73395122804 X-purgate-type: spam X-purgate-size: 5239 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844160388158500 Content-Type: text/plain; charset="utf-8" Some traps taken by Xen on behalf of a guest can't or shouldn't be handled by the hypervisor and have to be reflected to the guest's own S-mode trap handler instead: the access faults which handle_guest_page_fault() injects for a fault that can never become an emulated access, and, later on, a fault taken by the hlv/hlvx sequences of riscv_read_guest() while accessing guest memory on a vCPU's behalf. Implement trap_redirect(), until now a BUG_ON() placeholder, for that purpose. It makes the trap appear to the guest as if it had been taken directly in VS-mode: the trap information is transferred to the guest's virtual supervisor CSRs and the vCPU is resumed at its exception vector in supervisor mode, following the trap entry rules of the RISC-V privileged specification. Add the STVEC_* definitions needed to tell the BASE and MODE fields of vstvec apart. The implementation is based on kvm_riscv_vcpu_trap_redirect() from Linux, with a few deviations: - The function reads and writes physical VS-mode CSRs, so it is only meaningful for the currently running vCPU. Instead of taking a struct vcpu argument, it always operates on current. - The MODE field of vstvec is masked off explicitly when computing the exception target PC (exceptions always vector to BASE), rather than relying on the hardwired zero bit of sepc to drop it on VM entry. - Assertions document the preconditions: the trap must have been taken from virtualized mode (hstatus.SPV set), and only synchronous exceptions may be redirected - interrupts must be injected via hvip instead, so that the hardware performs VS-mode trap entry itself, respecting vsstatus.SIE and vectored vstvec dispatch. Signed-off-by: Oleksii Kurochko --- Changes in v2: - Add new defines STVEC_*. The STVEC_MODE_DIRECT/_VECTORED values are currently unused and were included because riscv encoding header is a spec mirror full of unused encodings. - Use STVEC_BASE_MASK instead of open-coding it. - Rename riscv_vcpu_trap_redirect() to trap_redirect(): unlike its KVM counterpart the function takes no vCPU argument, it implicitly operates on current, so "vcpu" in the name describes nothing. --- xen/arch/riscv/include/asm/riscv_encoding.h | 6 +++ xen/arch/riscv/traps.c | 50 ++++++++++++++++++++- 2 files changed, 55 insertions(+), 1 deletion(-) diff --git a/xen/arch/riscv/include/asm/riscv_encoding.h b/xen/arch/riscv/i= nclude/asm/riscv_encoding.h index 2d2e7e11b3ef..b2071f47587c 100644 --- a/xen/arch/riscv/include/asm/riscv_encoding.h +++ b/xen/arch/riscv/include/asm/riscv_encoding.h @@ -109,6 +109,12 @@ #define SIP_SSIP MIP_SSIP #define SIP_STIP MIP_STIP =20 +/* stvec/vstvec: MODE is bits [1:0], BASE is bits [XLEN-1:2] */ +#define STVEC_MODE_MASK _UL(0x3) +#define STVEC_MODE_DIRECT _UL(0x0) +#define STVEC_MODE_VECTORED _UL(0x1) +#define STVEC_BASE_MASK (~STVEC_MODE_MASK) + #define PRV_U _UL(0) #define PRV_S _UL(1) #define PRV_M _UL(3) diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c index 9cd37d943be1..8372f34497ad 100644 --- a/xen/arch/riscv/traps.c +++ b/xen/arch/riscv/traps.c @@ -294,5 +294,53 @@ enum mc_disposition arch_do_multicall_call(struct mc_s= tate *state) /* Redirect trap to Guest. */ void trap_redirect(const struct trap_info *trap) { - BUG_ON("unimplemented"); + struct cpu_user_regs *regs =3D vcpu_guest_cpu_user_regs(current); + unsigned long vsstatus =3D csr_read(CSR_VSSTATUS); + + /* + * Redirecting a trap makes sense only if the trap was taken from + * virtualized mode, i.e. sret is going to return to VS-mode. + */ + ASSERT(regs->hstatus & HSTATUS_SPV); + + /* + * Only synchronous exceptions can be redirected. Interrupts must be + * injected via hvip instead, so that the hardware itself performs + * VS-mode trap entry, respecting vsstatus.SIE and the vectored + * dispatch (BASE + 4 * cause) if vstvec is configured so. + */ + ASSERT(!(trap->scause & CAUSE_IRQ_FLAG)); + + /* Change Guest SSTATUS.SPP bit */ + vsstatus &=3D ~SSTATUS_SPP; + if ( regs->sstatus & SSTATUS_SPP ) + vsstatus |=3D SSTATUS_SPP; + + /* Change Guest SSTATUS.SPIE bit */ + vsstatus &=3D ~SSTATUS_SPIE; + if ( vsstatus & SSTATUS_SIE ) + vsstatus |=3D SSTATUS_SPIE; + + /* Clear Guest SSTATUS.SIE bit */ + vsstatus &=3D ~SSTATUS_SIE; + + /* Update Guest SSTATUS */ + csr_write(CSR_VSSTATUS, vsstatus); + + /* Update Guest SCAUSE, STVAL, and SEPC */ + csr_write(CSR_VSCAUSE, trap->scause); + csr_write(CSR_VSTVAL, trap->stval); + csr_write(CSR_VSEPC, trap->sepc); + + /* + * Set Guest PC to Guest exception vector. + * + * vstvec's MODE field is not part of the address. Exceptions always + * target BASE regardless of MODE, so mask it off explicitly instead of + * relying on the hardwired zero bit of sepc to drop it. + */ + regs->sepc =3D csr_read(CSR_VSTVEC) & STVEC_BASE_MASK; + + /* Set Guest privilege mode to supervisor */ + regs->sstatus |=3D SSTATUS_SPP; } --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844156; cv=none; d=zohomail.com; s=zohoarc; b=PacDprG/OTRWPROzdkGkLI8113cfDIDxf5Eez0rFK6YL5s7hrTZYX7benx8SE3xpJQ/HYvSFkrAL2is3z6oEuZwbG6kmxU9aLZMs5HEfiIgJqxtxj+wvyDjUApyfaomaC2XYB0Qf3DBO5xgVux66d7zJsPeg1nBXZXh3N1mxmcU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844156; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=HQi5AqxjI4j3kdKeC5mUOmbX7W1Kjge/ElYxM922heI=; b=Ez3qdWKUJRvaDPcV9a4WHdxKm/Ryn8dsLAn3PBRT0hnnfHX6uapVXOj8wG5NiZ4QD6ct3yv45RKIF9BKHontTlnL4mWHz6VafoygZ59794sGRRdjMznsiih7qdr9ha3FrmWo8ppBoaKJdAwAmyI1mMZSTELM/Rqz0q4qhCmqpD0= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844156380572.340248430903; Thu, 27 Aug 2026 08:22:36 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400960.1636709 (Exim 4.92) (envelope-from ) id 1wzbvj-0003Q8-RX; Thu, 27 Aug 2026 15:22:15 +0000 Received: by outflank-mailman (output) from mailman id 1400960.1636709; Thu, 27 Aug 2026 15:22:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbvj-0003Nc-4E; Thu, 27 Aug 2026 15:22:15 +0000 Received: by outflank-mailman (input) for mailman id 1400960; Thu, 27 Aug 2026 15:22:13 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvh-00031n-Ef for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:13 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvg-009kzH-RF for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:12 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a905616-2eae-0a2a0a5409dd-0a2a4501a8e6-44 for ; Thu, 27 Aug 2026 17:22:12 +0200 Received: from [209.85.221.52] (helo=mail-wr1-f52.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a905624-5984-0a2a45010019-d155dd34dcb0-3 for ; Thu, 27 Aug 2026 17:22:12 +0200 Received: by mail-wr1-f52.google.com with SMTP id ffacd0b85a97d-47f92e3c14bso1868714f8f.0 for ; Thu, 27 Aug 2026 08:22:12 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:11 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844132; x=1788448932; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=HQi5AqxjI4j3kdKeC5mUOmbX7W1Kjge/ElYxM922heI=; b=rwtMwSBiR5NkKgDTUPZfbhyo9o0SOhG6JROO7CCD3nrCGG8ZwcFBRdrjkkQ0UnhrX8 W40LESvDFYoKAK8NFHxapD32IDYzd7Vb9W65MamB+CZuKb74hKKzOwmTtWz/z2hHjSeS 26c/1X0lc9iM4laNChWoY36Hr7OJwejoz83PhDCQ6MUogw5rj6Di4xmUZVejdHgO05Ld RVLEsG74Nv0LgoFjEAX5NvHm22SjVsopNKF27MaZ5spmSOATtP9/zD52B9VZauNhe7aQ JLBkrtknplPgkQeooqYxkKUfOtkJsiJzmrqNhLklDl8T6X1FgcifdzBBJb4bQgcZJw2o y8wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844132; x=1788448932; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=HQi5AqxjI4j3kdKeC5mUOmbX7W1Kjge/ElYxM922heI=; b=cntuibtT4VBH2uHzLIGY9/TtilVJWrgk5BYWIgygTm2TfxJbaYpaR5X0AbHL9THI47 6PDlV9yKv+KM0MNYj3SRU8iRee88Km6a3/HZ/Twp0Gf04kT80d1mge8hyE0omuKpSwRC bRzY/g4qutKPuXmltb4IBjgm+oYPENOXVyvW9qPneGV4O5HIFWpb0di0FpxQ5WZSlbwq mVtVJyzcK07zeqqfSnf8XlA/B6Ts/ksfX4AorD7YtiBvPOTc7dTfSwIuLQ5LXdlZCxa5 Igr7s/4+Torga6dKPbvD2vEXcYfGe5AUdTmZepMXxKuu3D5cL46khzFdB5AcDpKP83Aj Skww== X-Gm-Message-State: AFuF++kQhQCbr84Cd6hfsJDMhBfzCKYWzKogqEoH1QqwAjYQTSoZvuAQ 1A1LejTkv8zN8pLTOOVn1KmABTBMDKAqLvSQr0yG5ilFkS23B7zSZN7YCTzBxQ== X-Gm-Gg: AR+sD10t1AuaL+VGPfouRJKvtEgPaM8hQEV/6MGuhdEY/LdA1KpDlNZPoJ1ZyHIt/AM kS2onxTaHZsxRTI0GMJjBgdNUrRedgxVbUHMITB+iKPqE49NAmQ5XJ9Grau3s/jV0H1vpZHi4cA +jfLzc19iy4fPnaz13EZpJThPiDv+FTzpQFVBe+lRcsTMD1a6jtbGVu6OfqpeCZk5QNgf0sstml /2zAAOm6vyWr/2VUwdlnReAKe/4fciXXn0OLo/87fVW/2RcpFfsgl1pAEEKlZEuDxO0itLJGZHx lvFL3yTSCUo9MjhBZS9LYWdAhlyCHxp1dlUDLb/Yw5YdenuUqMBa0cD7DokX/jlPHH5Yf9jkF1V Jl7jX8LCpMW0K4M5rYJYV9thpBlsl/7yt/3jCAq8EZ/IhiQ7I1VKHxfdz8tEh/0pQ2v+jPCN00Y rI2WBd2Ix1eSncyPZ5bGs3D3Vi7ANNxSoMfNwzXzAsJ4IU1VijipkHKXzxAmBDL/obZYRtugCUb d4ip6mQiSVDYymK8CAmkr+uN9Tp9vhgSHRldLQCbp4= X-Received: by 2002:a05:600c:1d1d:b0:499:737c:8a8b with SMTP id 5b1f17b1804b1-499dc81eb1emr193079615e9.12.1787844132127; Thu, 27 Aug 2026 08:22:12 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 20/39] xen/riscv: detect Shtvala Date: Thu, 27 Aug 2026 17:21:04 +0200 Message-ID: <611683b3d2e3b836d08d0499f7caff782ba80a34.1787838835.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d62444/1787844132-1E27A757-2AF5C80E/10/73395122804 X-purgate-type: spam X-purgate-size: 2034 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844158299158500 Content-Type: text/plain; charset="utf-8" Shtvala says that htval is written with the faulting guest physical address on a guest-page fault. The H extension itself allows an implementation to write htval with either that address or with zero, so where the extension is absent a zero htval cannot be told apart from a genuine fault on guest physical address 0-3. It is not offered to guests. Shtvala describes the HS-mode trap interface, which a VS-mode guest never sees, and the H extension it belongs to is already withheld from guests. Its guest-facing counterpart is a separate extension, Shvstvala. Signed-off-by: Oleksii Kurochko --- Change in v2: - New patch. --- --- xen/arch/riscv/cpufeature.c | 1 + xen/arch/riscv/include/asm/cpufeature.h | 1 + 2 files changed, 2 insertions(+) diff --git a/xen/arch/riscv/cpufeature.c b/xen/arch/riscv/cpufeature.c index 4bcbf56cb694..09a06f12318c 100644 --- a/xen/arch/riscv/cpufeature.c +++ b/xen/arch/riscv/cpufeature.c @@ -195,6 +195,7 @@ static const struct riscv_isa_ext_entry __initconstrel = riscv_isa_ext[] =3D { RISCV_ISA_EXT_ENTRY(zba, RISCV_ISA_EXT_GUEST_ANY), RISCV_ISA_EXT_ENTRY(zbb, RISCV_ISA_EXT_GUEST_ANY), RISCV_ISA_EXT_ENTRY(zbs, RISCV_ISA_EXT_GUEST_ANY), + RISCV_ISA_EXT_ENTRY(shtvala, RISCV_ISA_EXT_GUEST_NONE), RISCV_ISA_EXT_ENTRY(smaia, RISCV_ISA_EXT_GUEST_ANY), RISCV_ISA_EXT_ENTRY(smstateen, RISCV_ISA_EXT_GUEST_ANY), RISCV_ISA_EXT_ENTRY(ssaia, RISCV_ISA_EXT_GUEST_ANY), diff --git a/xen/arch/riscv/include/asm/cpufeature.h b/xen/arch/riscv/inclu= de/asm/cpufeature.h index 2973eb13a513..ac8c68007072 100644 --- a/xen/arch/riscv/include/asm/cpufeature.h +++ b/xen/arch/riscv/include/asm/cpufeature.h @@ -36,6 +36,7 @@ enum riscv_isa_ext_id { RISCV_ISA_EXT_zba, RISCV_ISA_EXT_zbb, RISCV_ISA_EXT_zbs, + RISCV_ISA_EXT_shtvala, RISCV_ISA_EXT_smaia, RISCV_ISA_EXT_smstateen, RISCV_ISA_EXT_ssaia, --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844162; cv=none; d=zohomail.com; s=zohoarc; b=bpVvczh64FNEKaBZfbbhW3l1q00vk/x9Sk+8o1CuHCbT978plWU2cB2IqAr0vPc3V8OYPAqx7mVlQZTzHEk+nlT7WXCe/WzSLwQtPjzzxgarVwS1Kid/HoVvDYJH7OCxM6R6EtV6I8gUfq5IZRKq65tiAWk8e12s1Rf1j/f4Hbo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844162; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=pDNxaENCE/QvrI+SlRLhTcL902ueqXFbgva0UVPXBwU=; b=Drqdj4Q/BPCKm7mWfPniDuDkjHicIb0BSy0PHWkF2hwnjf+Ses+XecjMXR+dYukQEHNPX1eGqWBNlJK5xd87r2No4tLqa0uP2BmhA8yBpupOJHTrX9HAcQrKjyC14EMZtR7stVQwK+Xaj0sqmZbZpVbW3eIExllFueHHnBdIjTw= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844162731645.0807580097475; Thu, 27 Aug 2026 08:22:42 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400962.1636718 (Exim 4.92) (envelope-from ) id 1wzbvl-0003s0-UI; Thu, 27 Aug 2026 15:22:17 +0000 Received: by outflank-mailman (output) from mailman id 1400962.1636718; Thu, 27 Aug 2026 15:22:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbvl-0003pI-Bx; Thu, 27 Aug 2026 15:22:17 +0000 Received: by outflank-mailman (input) for mailman id 1400962; Thu, 27 Aug 2026 15:22:15 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvi-0003IQ-VS for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:15 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvi-009kzH-Af for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:14 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a905616-2eae-0a2a0a5409dd-0a2a4501a8e6-48 for ; Thu, 27 Aug 2026 17:22:14 +0200 Received: from [209.85.128.48] (helo=mail-wm1-f48.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a905626-5984-0a2a45010019-d1558030b0f2-3 for ; Thu, 27 Aug 2026 17:22:14 +0200 Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-49b0dbfbf7bso9579045e9.2 for ; Thu, 27 Aug 2026 08:22:14 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:13 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844134; x=1788448934; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=pDNxaENCE/QvrI+SlRLhTcL902ueqXFbgva0UVPXBwU=; b=m769sHb5B6GxcJ3rq7HDto7Tk4vtQZysLLknD2LEEskGtoW5U28L9dBuvuoi9Svt0K xbWw4zW8MvGD9lxwFoisyhGPfDORfgjNLe6rXZ+ypZ6ZDqasR+VSpE6t6cj/0pn0PgRC reEfO4Zmqh8KKlmy94mdTsfl8BVXHgANB97eeUTscM2efqjLIL9+wAWZPKh/pTaEIzyM TeXTkMO0IybDDFpVDE8S5jpSqLXyVHmSGq8uhkhvfiSeaq05VqpMzEXZFMtF4FTbblA0 PjY5Sh5zuTiZdniMJMS3zR95xyjTJFgDTxUFT+qwWfOC2sNJLtVELRlXGwBZRRZBOiTF 7vfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844134; x=1788448934; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=pDNxaENCE/QvrI+SlRLhTcL902ueqXFbgva0UVPXBwU=; b=Uu0w3n474tvMpTLsyTniJnynHGKpZ9utDWoqdRb6RSUbyRtzlHzGrWbDtbsUfhjCUd GUy3hAoeLXgnrj8yhUhFY53ZvkF6L4DcEsQOaOYvmXYiQuhVpSBmhjGioNdYuyTzMPCZ p3mmk87GzUyC2jkolUOScN+kpP45GnNoJ0bNojXNTa0TqmjNxoqvqENCHuwe+afa2Qmt jJDEdtk5TXKxu5hrpV+wTUoYpE27xDDjIiOItY8NywuudqjdfFm8Zh6ZVPvawS4Etk4S qHUw8tIXbypSSnNG87mMwKmTpoD5FG/FycnhRylw/ju7bBsL+xgWSKSXVvFSAt/q04N7 mKGw== X-Gm-Message-State: AFuF++mUliLrdvDEPEdUGHcdl8gBPLmgeQ2az8c3j83m0R6hkwg8168/ L4RYq8j2Y860E7931qQFAEvvTw9b46FMst0Yv+hDCOYI/zbBODu4XgkNNUh+pg== X-Gm-Gg: AR+sD104SVGq/LKOnTAI8g9g7yV8I5ILJCeV3IYnBgJiejecNlVLd1tu6azePoUbPNf OBvzQwLYU0K3keHJz6urBSmY4fhDFdHGej2TAv49c/VZ66sP3mUX/fmcj1CndqR5JyxDpdYSIeb 447yfzzG6byHOIH2Y+hiUdeYfUu5GgjjA6QQvdyVsL1rv4KCHOgDhpS63qwByDScxodq5zJISZi 4t3XrhwJLrWtPYrKt5y/DG8r9gDNa4eQCgquR6fBqc8H2KfQhh/S2/rRgEDvmhdtAFvHmpSziwP 05EGEmu5lLew0yB53y4qpJ1tAJqx/AH5jKhy8aNkKdcbjd/Y243i6t9726/wCj7e4TSwsn6ZF5q i6tJvnP/j8EDLZGd00bjiF9gH03FhBH7XV/2vNzrbSxiEoVcKRsij+8u3mdeTczByHrjbAn3Q3m xLBFVzO/FQutfvg5cFAAVVSj8Mvs0WIdCdshFQ/frJCx+wGs6nakpzXBlu5vFrQZgtLLn5NwpfJ i3Y4kGbbYmrWEvKBckJ/gzeipuTHObbJBJLaUd1e9U= X-Received: by 2002:a05:600c:1c0a:b0:499:a79a:694d with SMTP id 5b1f17b1804b1-499dc6f532amr150493855e9.4.1787844133498; Thu, 27 Aug 2026 08:22:13 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 21/39] xen/riscv: resolve the faulting guest physical address Date: Thu, 27 Aug 2026 17:21:05 +0200 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d62444/1787844134-1F66C757-BC7A22B6/10/73395122804 X-purgate-type: spam X-purgate-size: 3536 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844164377158500 Content-Type: text/plain; charset="utf-8" Take the guest physical address from htval and stval: on a guest-page fault htval holds it shifted right by 2, so that an address wider than XLEN fits, and stval holds the faulting guest virtual address, whose two least significant bits are those of the guest physical address. The shift is done on paddr_t rather than on the raw register: a guest physical address is 34 bits wide on RV32 with Sv32x4, so shifting an XLEN-wide value would drop its top two bits. Those two low bits come from stval only for a fault on an explicit access. Where one is taken on an implicit access made for VS-stage translation htval holds the address of the VS-stage PTE which could not be read, while stval still holds the guest virtual address which started the walk, and the low bits of the address written to htval are zero instead. htinst tells the two apart, which is what the spec points at it for. stval needs no check against an ISA extension: a guest-page fault writes it with the faulting guest virtual address regardless. Sstvala would not be the right thing to test for either (it covers stval across every trap type which writes it, a wider guarantee than what is needed here). htval does need one. The H extension lets an implementation write it with either the faulting address or zero, so without Shtvala a zero htval cannot be told apart from a genuine fault on guest physical address 0-3, and the address has to be recovered by decoding the access and walking the VS-stage page tables in software instead. That is left as a TODO, and until it is written such hardware panics rather than acting on an address which may not be the one which faulted. Signed-off-by: Oleksii Kurochko --- Changes in v2: - New patch. --- --- xen/arch/riscv/emulate.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/xen/arch/riscv/emulate.c b/xen/arch/riscv/emulate.c index f9da0751049c..ff530ef2df74 100644 --- a/xen/arch/riscv/emulate.c +++ b/xen/arch/riscv/emulate.c @@ -9,6 +9,7 @@ #include #include =20 +#include #include #include #include @@ -62,10 +63,28 @@ static bool htinst_is_pseudo(unsigned long htinst) } } =20 -/* Reconstruct the guest physical address of the access which faulted. */ +/* Resolves the guest physical address the access faulted on into @gf->gpa= . */ static void resolve_faulting_gpa(struct guest_fault *gf) { - BUG_ON("unimplemented"); + /* + * A zero htval is either a genuine fault on guest physical address 0-= 3, or + * an implementation which does not report the address at all; only Sh= tvala + * tells the two apart. + * + * TODO: where it is absent, recover the address in software rather th= an + * giving up. + */ + if ( !gf->htval && + !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_shtvala) ) + panic("Shtvala isn't supported by h/w; s/w VS-stage walk required\= n"); + + /* + * htval does not carry the two low bits of the address: for an explic= it + * access they are those of the faulting guest virtual address in stva= l, + * and for an implicit access made for VS-stage translation they are z= ero. + */ + gf->gpa =3D ((paddr_t)gf->htval << 2) | + (htinst_is_pseudo(gf->htinst) ? 0 : (gf->stval & 3)); } =20 static int emulate_load(const struct guest_fault *gf) --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844159; cv=none; d=zohomail.com; s=zohoarc; b=LVhpofJHSBvPUGOmhJoAQ+4QD6IaDk6rAlG4E2nxs922jpwMF7IeLNujpBQaSFWq2wuu5zQuuCvrNyG87/CDkZ/ruIXm1GeMhD6aoCEIp6kej4iYL8PWLedfLOWICRMXH8wNSSKkJsRuaigXjWYOHEymU7BLHiE3fx4G8DWwRMg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844159; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=aSYcksaoNZwls6A65DTca2yUNFfZ7PKVnJOQ7ecrw0c=; b=QuYOdLimu0d2NrZmj+c4VwiyqAMF0qYvW21dTkDuNqc5tIKvPMrNCcGliKdhZuG9FV7Ap5QNFU272LNIMdDZ5sYoxjtWe7exZ++KvVq6OvtRUodxViV5OtOkwvlBKPsFkQ4i2e0C3LKGtnObRPmqUC+AkCDITze4XvAp0HA/Bd8= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 178784415965154.70946028256469; Thu, 27 Aug 2026 08:22:39 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400966.1636724 (Exim 4.92) (envelope-from ) id 1wzbvn-00044q-B0; Thu, 27 Aug 2026 15:22:19 +0000 Received: by outflank-mailman (output) from mailman id 1400966.1636724; Thu, 27 Aug 2026 15:22:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbvm-00043E-KC; Thu, 27 Aug 2026 15:22:18 +0000 Received: by outflank-mailman (input) for mailman id 1400966; Thu, 27 Aug 2026 15:22:16 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvk-0003cR-FE for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:16 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvj-003Nzp-Rn for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:15 +0200 Received: from [10.42.69.11] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a905627-8faa-0a2a0a5109dd-0a2a450bdcc6-0 for ; Thu, 27 Aug 2026 17:22:15 +0200 Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com) by tlsNG-42698a.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a905627-b7e8-0a2a450b0019-d155802eb420-3 for ; Thu, 27 Aug 2026 17:22:15 +0200 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-49b14637dfdso5514575e9.0 for ; Thu, 27 Aug 2026 08:22:15 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:14 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844135; x=1788448935; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=aSYcksaoNZwls6A65DTca2yUNFfZ7PKVnJOQ7ecrw0c=; b=P4thFkEW1tDIghNFmt1iHTz8MRejqDB8yojr3dD15BDDWkiu+bU+O6x0vJZhQxkq11 0zzQpARafoHQiSdxTTsB8xuBXeweg7wxrxfdt1bZhT/dGkAaKwXeHZwzbZyVlAH0ezte a17evhYm7NOmvTzdWRGkkgTm930D7b5174GcZSyH+XesTzBPjsrFLkIk4WgOuM8EUOMB v6Nrvdca+x9BR+UaAfeRy57pB82QQ3yXGS9Cu4KlJnvkpCGZS7Y6zGfPbHvN3AS7eMvZ 3trKrkcGz3N/SC3b0YsnFGQjv26oWZ69pqDDnH2m3mH0Z/6zp3HYI1s9s5gFrQwiTyks FWzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844135; x=1788448935; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=aSYcksaoNZwls6A65DTca2yUNFfZ7PKVnJOQ7ecrw0c=; b=IgWKfrK3vBRxA0tkV5szV06FMQpaltv3iUa7zsg16ZfgvJLaRoZi1iuuCUUtkk/gcf nuhhYK0q1Wlq1qGOKe2VAAYbwyOP1vXXW8HueKSGwi76Yf69fkbMYOknv5coaCe8mTud umbUUxm65ra+naq6FZaccSTenssXC2UbG3sxVdwhX+B8eCbhimcw/8P7XHfXUl9ltzF0 dDIUPpCgev1lXgc0KDPNYxP6xAB5zFD6pqkfyCQ0qkVYoRSJ9H4u07TgaEwD16clLwbj sfjBs7YtzMflF+Amdu+cCdxPtGgNMecWS/82Yi7UHglaFQfURTxffd12ORi4ydvJy9CO chSg== X-Gm-Message-State: AFuF++lD9Bb/c9dYyfJpWM5TJPiKVdi6kbTefBtbKHDauZ9HgM2xc7JW XA7hgRek10BE7ta29FP4K55eTrdy5wgMaQ9JHTiolSv9ymvSIWjMWguPdDko5A== X-Gm-Gg: AR+sD11QZITBkBdPcDwTtBAyq46ljeYsAP9M+OdQtR7VAHAZjdBiMrkUPV1ZscP6qqg E64gLH2qqDnBua1aizy6kRuRRW6AGuZQmUBHz7wCZBa5voJ7Cyp7qRf9cJFa6yRO0Z6XEmvjSTl jqOzBqxd7mfH0BiEQ4qr2M4ZR+SPRghZbrSfynivInTJ03d47wTXf+PVKSvGTej/YF93/s2ZWBu jeb9zYch8gaIDqQ42x/jhQKfgsWItccK3VD8E0pRSuq8t5srDGY8Ecuf1wU3Nkfs6SxrJ+gOApS SrG4cVHV1OdoTfhPSR4V02mJwQoqZGFAGTqa8zLTo1Me5BQB0zUAw1ep5OJ39ajTjvt4l/bds/D Xz78cy0hq8LAAoRIebBZXvJSzvSOwM2buS5SbfkswcZOCHQ47qDB4bmpeaaj6fmXqdjnSvojsHE wG0OjEkLIubLOTov8pPpmE1wbkGJU6OHYsEVq3pcnasHMNDjBfUTScL46FT9X1Y2EHYsyw7yvmw QljXDHWYTq3l3La2GyFVfnMGATfG9cT X-Received: by 2002:a05:600c:1c09:b0:49b:8f01:7119 with SMTP id 5b1f17b1804b1-49b8f017186mr73761075e9.14.1787844134926; Thu, 27 Aug 2026 08:22:14 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 22/39] xen/riscv: add guest memory read helper Date: Thu, 27 Aug 2026 17:21:06 +0200 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-42698a/1787844135-194C39EA-EDA43B15/10/73395122804 X-purgate-type: spam X-purgate-size: 6481 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844160439158500 Content-Type: text/plain; charset="utf-8" Introduce riscv_read_guest() to allow Xen to safely read guest memory using HLV/HLVX instructions while reliably capturing trap context. This is required for instruction fetch emulation and MMIO decoding, where Xen must inspect guest memory that may not be directly accessible and may fault. The implementation is based on kvm_riscv_vcpu_unpriv_read() from Linux, with one deviation: the hlv/hlvx instructions translate the guest address through the live vsatp/hgatp CSRs, i.e. through the address space of the currently running vCPU, so the function can only be called safely for current. Instead of taking a struct vcpu argument, it always operates on current directly. Signed-off-by: Oleksii Kurochko --- Changes in v2: - Rename riscv_vcpu_unpriv_read() to riscv_read_guest() and make the guest address the first parameter. "unprivileged" described how hlv/hlvx perfo= rm the access rather than what the helper is for, and "unprivileged guest" reads as a synonym for DomU although the helper works for any domain. - Drop the hstatus save/restore and the local_irq_save() protecting it: hstatus already belongs to the vCPU which trapped, as Xen never installs a value of its own and does not reschedule before returning to the guest. ASSERT() hstatus.SPV in the saved copy instead, which also documents that the helper is only usable while handling a trap from a guest. - Poison val with ~0UL and make [val] "+&r": the fixup for the first access resumes past the loads without writing it, so a caller which checks trap->scause is no longer handed an uninitialized value. - Describe the trap_info write with a "+m" (*trap) operand instead of a "memory" clobber; the exception handler writes that structure and nothing else. - Combine the two halfwords with slli/or instead of sll/add, and use bnez for the instruction length check. - Turn the hlv.d/hlv.w selection into #if/#elif with an #error default, rather than silently using hlv.w for anything that is not RV64. - Document that at most two halfwords are fetched, i.e. that encodings wider than 32 bits are unsupported and cannot be completed by calling the helper again at guest_addr + 4, since the length check would then be applied to a continuation halfword. --- --- xen/arch/riscv/guestcopy.c | 87 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 87 insertions(+) diff --git a/xen/arch/riscv/guestcopy.c b/xen/arch/riscv/guestcopy.c index 8a89212e0bea..b2327822acaa 100644 --- a/xen/arch/riscv/guestcopy.c +++ b/xen/arch/riscv/guestcopy.c @@ -6,6 +6,7 @@ #include =20 #include +#include =20 #define COPY_from_guest 0U #define COPY_to_guest BIT(0, U) @@ -114,3 +115,89 @@ unsigned long copy_to_guest_phys(struct domain *d, pad= dr_t gpa, void *buf, return copy_guest(buf, gpa, len, GPA_INFO(d), COPY_to_guest | COPY_gpa); } + +/* + * Read machine word from guest memory + * + * @guest_addr: Guest address to read + * @read_insn: Flag representing whether we are reading instruction + * @trap: Output pointer to trap details if something went wrong during re= ad + * + * The hlv/hlvx instructions translate guest_addr through the live + * vsatp/hgatp CSRs, so the read is only meaningful for the address + * space of the currently running vCPU. + * + * At most two halfwords are fetched when @read_insn is true, i.e. encodin= gs + * wider than 32 bits are not supported. Such an encoding cannot be comple= ted + * by calling this function again at @guest_addr + 4: the length check is + * applied to the first halfword read, which would then be a continuation = of + * the instruction rather than its opcode. It is up to the caller to reject + * anything that is neither a 16- nor a 32-bit encoding. + */ +unsigned long riscv_read_guest(unsigned long guest_addr, bool read_insn, + struct trap_info *trap) +{ + /* + * Poison the result: if the very first access faults, the fixup skips + * over the loads without writing it. Callers must check trap->scause. + */ + unsigned long val =3D ~0UL, tmp; + + /* + * hlv/hlvx use hstatus.SPVP for the privilege of the access, and the + * live vsatp/hgatp for the translation. Xen never installs a value of + * its own in hstatus (it is only saved on trap entry and restored + * before sret) and it doesn't reschedule before returning to the + * guest, so all three still belong to the vCPU which trapped. + * + * Check the saved copy rather than the live CSR: a nested trap taken + * from HS-mode clears hstatus.SPV in the CSR (but leaves SPVP alone). + */ + ASSERT(vcpu_guest_cpu_user_regs(current)->hstatus & HSTATUS_SPV); + + if ( read_insn ) + { + asm volatile ( "\n" + "1: hlvx.hu %[val], (%[addr])\n" + ASM_EXTABLE_TRAP_INFO(1b, 3f, %[ti]) + " andi %[tmp], %[val], 3\n" + " addi %[tmp], %[tmp], -3\n" + " bnez %[tmp], 3f\n" + " addi %[addr], %[addr], 2\n" + "\n" + "2: hlvx.hu %[tmp], (%[addr])\n" + ASM_EXTABLE_TRAP_INFO(2b, 3f, %[ti]) + " slli %[tmp], %[tmp], 16\n" + " or %[val], %[val], %[tmp]\n" + "3:\n" + : [val] "+&r" (val), [tmp] "=3D&r" (tmp), [addr] "+&r" (guest_addr= ), + "+m" (*trap) + : [ti] "r" (trap) ); + + /* + * Although HLVX instructions' explicit memory accesses require ex= ecute + * permissions, they still raise the same exceptions as other load + * instructions, rather than raising fetch exceptions instead. + */ + if ( trap->scause =3D=3D CAUSE_LOAD_PAGE_FAULT ) + trap->scause =3D CAUSE_FETCH_PAGE_FAULT; + } + else + { + asm volatile ( "\n" + "1: " +#if defined(CONFIG_RISCV_64) + "hlv.d %[val], (%[addr])\n" +#elif defined(CONFIG_RISCV_32) + "hlv.w %[val], (%[addr])\n" +#else +# error "unsupported RISC-V variant: no hlv for a machine word" +#endif + "2:\n" + ASM_EXTABLE_TRAP_INFO(1b, 2b, %[ti]) + : [val] "+&r" (val), "+m" (*trap) + : [addr] "r" (guest_addr), [ti] "r" (trap) ); + } + + return val; +} --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844168; cv=none; d=zohomail.com; s=zohoarc; b=SnVn0kbjPA9xfXYxZAe39C3rpYkDrNQPoDM/VishhjJi0kz+thSvXhYOBruw5stP1mn+RwAHDKLwd2X6KPMiuJ4oNAqkLlXe9IK2UtBWTA+QjQC9vDJw6bkoHM7Iu+ytwpwDnr7drkZXYrvjU2xThxs/qWIzGXudqnDRvOhQQZs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844168; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=O2aB57chliXxE+zIo1eZYfWP0lSRPt7WRG4FJXknti4=; b=mi0+VVTntZwzLSVmLwnGa/zIUFpFxAxMjPtYzKUmnltvQZkKhUEOvPg1+l2ghUpfFg6twSFtL/cBlYz0YqXOdm4khGTYx6GmtmVW6P7c3jx5FgeeL/3qKd0fp+d94GDAgujJB1LeanHC/LU88eIyqo3nvNRy+kWepcUL68eGWnI= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844168770347.5575616005548; Thu, 27 Aug 2026 08:22:48 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400971.1636734 (Exim 4.92) (envelope-from ) id 1wzbvp-0004au-Rt; Thu, 27 Aug 2026 15:22:21 +0000 Received: by outflank-mailman (output) from mailman id 1400971.1636734; Thu, 27 Aug 2026 15:22:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbvo-0004X3-Os; Thu, 27 Aug 2026 15:22:20 +0000 Received: by outflank-mailman (input) for mailman id 1400971; Thu, 27 Aug 2026 15:22:18 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvl-0003tl-Sa for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:18 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvl-009l31-98 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:17 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a905628-2eae-0a2a0a5409dd-0a2a4503e5b2-2 for ; Thu, 27 Aug 2026 17:22:17 +0200 Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a905629-fae8-0a2a45030019-d1558035c14f-3 for ; Thu, 27 Aug 2026 17:22:17 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-49b8687630fso5775785e9.3 for ; Thu, 27 Aug 2026 08:22:17 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:15 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844137; x=1788448937; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=O2aB57chliXxE+zIo1eZYfWP0lSRPt7WRG4FJXknti4=; b=NGa+9EHTBEhUdobOYHqaiQrAQiFBV83n/E7u/zA8iU2jSq1z+OPyDkSHKcBkNbYEgg RQdOHzKybcnQBpFyr5e1CxhaMAwhgXQUtWDFqBnYZ5rzH63e1njzwKGusrd9t0Qz9sJ6 rjuoH3EozZQweJGttmGPw2z/yuClJS9BdhcnGu53Yaljroh7D+o4mi3p5cCib4q+4Nrb 23hLi2bICwf9B43mJOg/aZGTkKtgY0+K3GxXP7cjZQEAyKJ/hBxgOze6ZZb+84UZFJzi v25WjFMFyvSINpDTByHKLcnL8tSelrMKemblTzO9unPCElLNXKgxJkR2X4qMSWerx6XP j58g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844137; x=1788448937; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=O2aB57chliXxE+zIo1eZYfWP0lSRPt7WRG4FJXknti4=; b=PDZmZL9ykD0Gp/B1IDM6JP1LdNNLpX5yKmyZmCUpLPwoGFjge4kYL4qLzR9xG/9J2y Xb5nnroXegKUFKSj0jNlGzt3O/sNV1Q5EkayGcSLyzVroqkAhtP8USquhQZ+x3sRpwES qjGPoDa5AH7kYCiio6FZmYDVSU53OIcxpQPuXed4AEjExZd3fWhi6qohEv3X6QKLOrHW 8RNrXS7lXt/aB6z9tq4gNPo+1eGmw6fpsjs2hyT0Q1VPxGsL2OaoqHjm816VFpjzFi2m ik2zSQco5AOjAE4Nyo8rrqyVkjFR6fcrrNukV7uVuNWYdyR1nqbkSm2XKGi66ac7vWq0 rliw== X-Gm-Message-State: AFuF++kIf3+vyeI6weuseaYyLaZqIoSrrr28K0tlN9qzqD0hHXx8hqH8 NisnVDlxuluGdcjcUrILz7ERpydWF3/MGv5nY9ywOt3Ybmslt4nxfCkUbgsOWg== X-Gm-Gg: AR+sD103Yv5mbgC5oNSkblA3XSOq6xyqLrOLErsDMjVF/s+chy6QjQhStg+brMTXbLg WU6LPX7NY21wMeBvHlWpFNvDlqc2iSAG0AgwRlF96zyxSLTIsnzy8xCHiN1xazVbc7z5TaJzOv4 vppve0rn07M/FVJRLb2kMZvokKM1Lg4v9HqeYYrd3dmz4tSQ6/isIn2R+3LqFwYlTcBObvCVxUL 2Ti65M0H4m8lQSHwoMbiRH68KUHHFkhIi51GVAIuXHPgLOvEDMlQC6T7RtY4x/uF5acBnDsMTDS RWc3fftwCr7tcxbxYucNxF6/AKsqB5Mpo+AslbitXC0QCJSF4TKBADTghuwdMptsHO2eyOVhlah z34EjZVK2qniCRy6uchqYwQ4aDvDbf5sRg5NFhaggnsfIP4eqUxj3UA0UE8OEA4AcY1NZMrNGWO R6DYvXqsglFh6WVd0H5qtmzWGgv1M6P0OqYCkmmK/vS4EXkFD5TWL3deTFJyWe9VaYHSssRnDYm qbY2T3u0/a8eimCJ6ZNbRpEfILvHNpNcgC85JUkurI= X-Received: by 2002:a05:600c:3114:b0:499:4e47:eaf2 with SMTP id 5b1f17b1804b1-499dc6f5e13mr148726165e9.6.1787844136586; Thu, 27 Aug 2026 08:22:16 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 23/39] xen/riscv: look up the exception table for any trap taken in Xen context Date: Thu, 27 Aug 2026 17:21:07 +0200 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-33051d/1787844137-75EFF4E9-AF1765B4/10/73395122804 X-purgate-type: spam X-purgate-size: 3676 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844170406158500 Content-Type: text/plain; charset="utf-8" do_trap() consulted the exception table only for CAUSE_ILLEGAL_INSTRUCTION, which covers csr_read_safe() but not the hlv/hlvx sequences reading guest memory: those fault with load/store (guest) page fault causes and would reach do_unexpected_trap() instead of their fixup. Move the lookup ahead of the cause switch, and gate it on the trap having been taken in Xen context and not being an interrupt: - sepc of a trap taken from the guest is a guest VA/PA, which the guest can point at an address listed in the exception table; Xen would then act on that entry and, for EX_TYPE_TRAP_INFO, write through a pointer fully under guest control. Entries are matched by exact address, so this needs no more than a numerical collision. - an interrupt taken at an address listed in the table would otherwise be "fixed up" as if the access itself had faulted, silently skipping it and handing the caller the interrupt's scause as a fault cause. Returning early skips check_for_pcpu_work(), which is correct: that only runs for traps taken from the guest. With that in place a G-stage fault reaching the switch can no longer have been caused by an hlv/hlvx covered by an entry, so anything left must have come from the guest; assert as much. Cache the "trap came from the guest" test in a local, it is now used four times. Signed-off-by: Oleksii Kurochko --- Changes in v2: - New patch. --- --- xen/arch/riscv/traps.c | 28 ++++++++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-) diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c index 8372f34497ad..f5f83fce10ba 100644 --- a/xen/arch/riscv/traps.c +++ b/xen/arch/riscv/traps.c @@ -196,11 +196,34 @@ void do_trap(struct cpu_user_regs *cpu_regs) unsigned long cause =3D csr_read(CSR_SCAUSE); bool from_guest =3D cpu_regs->hstatus & HSTATUS_SPV; =20 + /* + * A synchronous trap taken in Xen context may come from an access don= e on + * a vCPU's behalf, e.g. the hlv/hlvx sequences in riscv_read_guest(), + * or from a probing access like csr_read_safe(). Both are covered by + * exception table entries which record the fault details for the call= er + * and resume execution past the faulting instruction. + * + * Traps taken from the guest must never be fixed up: sepc is then a g= uest + * address, which the guest could point at an address listed in the + * exception table, making Xen act on an entry (and, for EX_TYPE_TRAP_= INFO, + * write through a pointer) fully under guest control. + * + * Interrupts must be excluded too: one taken at an address which happ= ens + * to be listed in the exception table would otherwise be "fixed up" a= s if + * the access itself had faulted, silently skipping it. + * + * Returning early skips check_for_pcpu_work() below, which is correct: + * that only runs for traps taken from the guest. + */ + if ( !from_guest && !(cause & CAUSE_IRQ_FLAG) && + fixup_exception(cpu_regs, cause) ) + return; + switch ( cause ) { case CAUSE_VIRTUAL_SUPERVISOR_ECALL: /* CAUSE_VIRTUAL_SUPERVISOR_ECALL should come from VS-mode */ - BUG_ON(!(cpu_regs->hstatus & HSTATUS_SPV)); + BUG_ON(!from_guest); =20 vsbi_handle_ecall(cpu_regs); break; @@ -232,9 +255,6 @@ void do_trap(struct cpu_user_regs *cpu_regs) break; } =20 - if ( fixup_exception(cpu_regs, cause) ) - break; - fallthrough; default: if ( cause & CAUSE_IRQ_FLAG ) --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844167; cv=none; d=zohomail.com; s=zohoarc; b=bNl72MG6uFhPcLZyP45Yc1kSsKRbc8Kes+7XJiOLWpP7Tkql8VW3ssvEMIjaSmJT+o1KqjdLy6UIXCLihNjq3tNGKEokJz5TFyIzHAyLJkjoogONfAEHnufldGTEbRKWLR8Z64i5wTEpItLA6cO6OTGtFnj+n1c/LNOFByr4BOs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844167; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=Saj873IO4zi5PbzkY/2SZpciSlU0AQy44WBooonhO3Q=; b=CuERRa3N5S8nMYbhfEJi+VTLy7c9keYfKKYXCd3sxxQc9Fyw/47I40IJS9nzA0ws3+ux9mqvimcQL0EWbOi8q9rqooSfnC6P7utX32kkVAstB5XN2vnIv/s3n2u05++6ZVexsIKDGufwe/6IEsjvq7Lre2+nffD+ZgYf1ToY7NY= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844166891632.9767280116047; Thu, 27 Aug 2026 08:22:46 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400975.1636742 (Exim 4.92) (envelope-from ) id 1wzbvt-0005LN-Gr; Thu, 27 Aug 2026 15:22:25 +0000 Received: by outflank-mailman (output) from mailman id 1400975.1636742; Thu, 27 Aug 2026 15:22:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbvs-0005EZ-90; Thu, 27 Aug 2026 15:22:24 +0000 Received: by outflank-mailman (input) for mailman id 1400975; Thu, 27 Aug 2026 15:22:20 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvn-00049Z-DL for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:19 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvm-003Nzp-OM for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:18 +0200 Received: from [10.42.69.9] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a905620-8faa-0a2a0a5109dd-0a2a45098620-28 for ; Thu, 27 Aug 2026 17:22:18 +0200 Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com) by tlsNG-bad1c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a90562a-be1a-0a2a45090019-d1558036b129-3 for ; Thu, 27 Aug 2026 17:22:18 +0200 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-499ae1c6471so14455615e9.3 for ; Thu, 27 Aug 2026 08:22:18 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:17 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844138; x=1788448938; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=Saj873IO4zi5PbzkY/2SZpciSlU0AQy44WBooonhO3Q=; b=LNr1qwvZhOSyv7bLbXK0X7n4opuxRPWy2SgiU1rCg2xeDjXa+gxafF+z4Ko66osxQ3 kFkL9pR1SADCAIcXAm6Lev1Hw+0MFMPvj6PvK4XH9wRd8dq43SQCqx3vu8R/Yj1qGe5V yIVceBUHg+bL2xuNvENbML2xQ2ZGkbjRF8Lsl8BXf9qZzrBMES60LVcIs5v/lxOOF2dv aW9LxD8nC2/CFhibugKZTXSFyNz9wtYPYorkU7/sLzNJ6WBJGji5qcDWUo7kltEY+Y8P lKxptkqKk47NPOIRaDwiZPzJk2UYUz3ENfRWeb/NfyHEA38qbgds5hdneoC1oEOIVhnx 17sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844138; x=1788448938; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=Saj873IO4zi5PbzkY/2SZpciSlU0AQy44WBooonhO3Q=; b=LstE/U8KnrYdMUQtERlgO3WP6h0TO32964mIH+kjLVzrmHCP2A8eUcB033fY87cLsS 7rymeP2IFpSAAdbRpCU247X3xDWalQlyCpPw/4I9CIqAewlKyaPjXLY+jEhw11bR4V4o 4tbs4nzjfEwfi2rMVsm2CGQG9UttThOz7H0HjRNXLPH1umwstU5/23u9u2VmFf4wlXKv ynl3PnDO6ksQi41+G4ioT4eNb/DddnklF0VUX7at60A3a/+3/97yahO4fJiCPwZqgGO1 PzBnJmc2zIrin+bLhqq+N+eOaZChlb/x+3C+xRnam69GdETt42Q9BkmOqSsd2IrnX4b3 9sCA== X-Gm-Message-State: AFuF++mSwDNTstsbl0zVabr4c4RCb+7EBYvJ/HUHx6EOPrD+HvWbqMrv QD53uU0bqoUlzPmEallbKv/isldoDfaNLYFnQ8BV7YvczEfW84s0WmqgjdRpUg== X-Gm-Gg: AR+sD11SYvnQOHEVu3GGNdTJ1A7etERHj7aFLhiyDwn1uleGSYJ22STm2FiT8sJQhls 1S06B1FD0NI4j3Q3B+XZPwc3ZGgNahLPLH2f3yqe1ommCoj1JdDkR+/u3C8I85WcoaDf1PEiXXr SOJsUTM7v9r30DxOm8IzgVoIQGmcn2qLNIT4FvCXyAbHHAvGPy0I4pAvMBTmneIFKOOliJE3AhG uLAlDz3mhX0esyP50qRXsUOjXdZpcFw1+JkHnyQyzS1C+KH8RmuVP0NWqidY17s4+QZY0Vc2XNh EM7OiG9ADuy6slu//sWwuCeJCx3ziAA8PFyF7NpxbLu9qcjgDZY8nfH1K3iEDApbtqhMxHarz3+ S35Pz/1/l76351NI4CT1mBNXSLoYEmgfx+nB1egNNAec7Zs4OaH4S539SaziZET3UrJ9Ch6/kPO zbk+laHyvY96rKRhQO6oi70Pz8gOywi+PRH7BlcbqyiwwqnfpR6QiM2KuTM1tOIRC9Yz597ZXfa kDbDPb7K6sOmXi+08nU/zWG9+uNXXBj X-Received: by 2002:a05:600c:8518:b0:499:a5c8:c6f3 with SMTP id 5b1f17b1804b1-499dc6e998cmr210406535e9.3.1787844137893; Thu, 27 Aug 2026 08:22:17 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 24/39] xen/riscv: add helpers for decoding a trapped load or store Date: Thu, 27 Aug 2026 17:21:08 +0200 Message-ID: <4c5361bda56e97f5338f4bc561498e018adbf618.1787838835.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-bad1c0/1787844138-BEAD8034-41E1D51C/10/73395122804 X-purgate-type: spam X-purgate-size: 15769 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844168462158500 Content-Type: text/plain; charset="utf-8" emulate_load() and emulate_store() will both need to obtain the instruction which caused a guest MMIO trap, decode it, and locate the register operand it names. Add what the two share, ahead of either of them being implemented: struct decoded_insn, insn_fetch_faulted(), decode_ldst_insn(), guest_xlen(), guest_gpr() and advance_pc(). The mask/match chain is adapted from Linux's KVM RISC-V implementation. Nothing calls any of this yet, so tag the functions __maybe_unused to keep the build going; the tags go away once emulate_load() and emulate_store() gain their bodies later. Signed-off-by: Oleksii Kurochko --- How this function could be used can be seen in the next patch. --- Changes in v2: - New patch. --- --- xen/arch/riscv/emulate.c | 330 ++++++++++++++++++++ xen/arch/riscv/include/asm/guest_access.h | 4 + xen/arch/riscv/include/asm/riscv_encoding.h | 10 + 3 files changed, 344 insertions(+) diff --git a/xen/arch/riscv/emulate.c b/xen/arch/riscv/emulate.c index ff530ef2df74..81a50643a5ec 100644 --- a/xen/arch/riscv/emulate.c +++ b/xen/arch/riscv/emulate.c @@ -5,6 +5,7 @@ */ =20 #include +#include #include #include #include @@ -13,9 +14,29 @@ #include #include #include +#include +#include #include #include =20 +/* + * Determine the trapped load or store instruction which caused a guest MM= IO + * trap. + */ +struct decoded_insn { + /* The instruction itself, and its length in bytes. */ + unsigned long insn; + unsigned int insn_len; + /* Width of the memory access, in bytes. */ + unsigned int len; + /* Number of the register operand: rd for a load, rs2 for a store. */ + unsigned int reg; + /* The access is a store rather than a load. */ + bool is_write; + /* The load zero-extends its result rather than sign-extending it. */ + bool is_unsigned; +}; + /* * The hardware-reported details of a guest page fault, gathered once by * handle_guest_page_fault() and passed down to the emulation of the fault= ed @@ -39,6 +60,71 @@ struct guest_fault { paddr_t gpa; }; =20 +static bool is_load_guest_page_fault(unsigned long scause) +{ + return scause =3D=3D CAUSE_LOAD_GUEST_PAGE_FAULT; +} + +static __maybe_unused void advance_pc(struct cpu_user_regs *regs, + unsigned int step) +{ + regs->sepc +=3D step; +} + +/* + * The effective XLEN of the guest at the point of the trap: hstatus.VSXL = for a + * trap taken from VS-mode, vsstatus.UXL for one taken from VU-mode. + * + * VSXL is consulted whichever mode the trap came from, as it also gives t= he + * width of vsstatus itself: where VSXL says 32, that register has no UXL = field + * to consult and VU-mode is 32-bit as well, there being nothing to config= ure. + * + * It is needed to decode a trapped instruction: the encodings which exist= only + * for XLEN=3D64 must not be recognized for a 32-bit guest. Besides those = simply + * being reserved there, the compressed ones are ambiguous: C.LD and C.FLW + * share the encoding 0x6000 (mask 0xe003), and likewise C.SD/C.FSW, + * C.LDSP/C.FLWSP and C.SDSP/C.FSWSP. + * + * IS_ENABLED() can't be used here as HSTATUS_VSXL is defined for + * __riscv_xlen =3D=3D 64 only, the field not existing on RV32 in the firs= t place. + */ +static __maybe_unused unsigned int guest_xlen(const struct cpu_user_regs *= regs) +{ +#ifdef CONFIG_RISCV_32 + return 32; +#else + unsigned long xl =3D MASK_EXTR(regs->hstatus, HSTATUS_VSXL); + + if ( (xl =3D=3D XLEN_FIELD_64) && !(regs->sstatus & SSTATUS_SPP) ) + xl =3D MASK_EXTR(csr_read(CSR_VSSTATUS), SSTATUS64_UXL); + + switch ( xl ) + { + case XLEN_FIELD_32: + return 32; + + case XLEN_FIELD_64: + return 64; + + default: + /* + * The field holds nothing else in practice: XLEN_FIELD_128 would = mean + * RV128, which no implementation provides, and the only value lef= t is + * reserved. ASSERT_UNREACHABLE() being debug-only, a width still = has + * to be answered in release builds. + * + * Answer 32, that being the safe way to be wrong: the decoder then + * fails to recognize the RV64-only encodings and emulation gives = up. + * Answering 64 for what may well be a 32-bit guest would instead = have + * it take C.FLW for C.LD and C.FSW for C.SD (see above), i.e. qui= etly + * emulate an access of the wrong width against the wrong register. + */ + ASSERT_UNREACHABLE(); + return 32; + } +#endif +} + /* * Is @htinst one of the pseudoinstructions reported for a guest page fault * taken on an implicit memory access done for VS-stage address translatio= n? @@ -87,6 +173,250 @@ static void resolve_faulting_gpa(struct guest_fault *g= f) (htinst_is_pseudo(gf->htinst) ? 0 : (gf->stval & 3)); } =20 +/* + * Where the value of a decoded instruction's register operand is held. + * + * Relies on x0..x31 being laid out at the start of struct cpu_user_regs in + * architectural register-number order; see the comment there. + */ +static __maybe_unused unsigned long *guest_gpr(struct cpu_user_regs *regs, + unsigned int reg) +{ + ASSERT(reg < 32); + + return REG_PTR(reg, 0, regs); +} + +/* + * Obtain the instruction which caused a guest MMIO trap, filling in + * @di->insn and @di->insn_len. It either comes transformed in htinst, or = has + * to be fetched from guest memory. + * + * Returns true if the fetch faulted in turn; the resulting trap has then + * already been redirected to the guest and there is nothing further for t= he + * caller to do. Where it returns false, @di has been filled in and emulat= ion + * is to continue. + */ +static bool __maybe_unused insn_fetch_faulted(const struct guest_fault *gf, + struct decoded_insn *di) +{ + unsigned long htinst =3D gf->htinst; + + /* + * A pseudoinstruction says nothing about the instruction the guest was + * executing, and comes with a guest physical address which isn't the = one + * that instruction accessed. handle_guest_page_fault() deals with suc= h a + * fault on its own, so no emulation can ever start for one. + */ + ASSERT(!htinst_is_pseudo(htinst)); + + if ( htinst & BIT(0, UL) ) + { + /* + * Bit[0] =3D=3D 1 implies trapped instruction value is + * transformed instruction or custom instruction. + * + * The transformation always yields the 32-bit format, with bits[1= :0] + * holding a marker instead of the original opcode bits: bit[0] se= t to + * flag the transformation, bit[1] clear if the trapped instruction + * was a compressed one. Restoring the opcode bits makes the value= the + * valid 32-bit encoding decode_ldst_insn() matches against. Its + * INSN_MASK_C_* cases exist for the branch below, where a compres= sed + * instruction is read from guest memory as is: a trapped one arri= ves + * here already expanded to its 32-bit equivalent, and the opcode = bits + * just restored keep it from matching those cases anyway. + * + * The length then cannot come from the value anymore, only from + * bit[1]. And only a 16- or a 32-bit instruction is ever reported + * this way: the standard load and store instructions the hardware + * transforms are all of one of these two lengths, anything else c= omes + * as the zero special value handled below. + */ + di->insn =3D htinst | INSN_16BIT_MASK; + di->insn_len =3D (htinst & BIT(1, UL)) ? 4 : 2; + } + else + { + const struct cpu_user_regs *regs =3D gf->regs; + struct trap_info utrap =3D {}; + + /* + * Bit[0] =3D=3D 0 implies trapped instruction value is + * zero or special value. With the pseudoinstructions ruled out + * above, only zero is left: the instruction has to be read from + * guest memory. + */ + + di->insn =3D riscv_read_guest(regs->sepc, true, &utrap); + if ( utrap.scause ) + { + /* + * If during getting of trapped instruction a fault happen in + * G-stage translation then CAUSE_LOAD_GUEST_PAGE_FAULT is + * generated. Such faults during this operation is considered = as + * bus error. + */ + if ( is_load_guest_page_fault(utrap.scause) ) + utrap.scause =3D CAUSE_FETCH_ACCESS; + + utrap.sepc =3D regs->sepc; + + trap_redirect(&utrap); + + return true; + } + + /* + * riscv_read_guest() fetches at most two halfwords, so a wider + * encoding has been read in part only and cannot be decoded here. + * + * Report an illegal instruction, which is what the guest would ha= ve + * got for such an encoding anyway: the ISA defines no instruction + * wider than 32 bits. + */ + if ( !INSN_IS_16BIT(di->insn) && !INSN_IS_32BIT(di->insn) ) + { + utrap.sepc =3D regs->sepc; + utrap.scause =3D CAUSE_ILLEGAL_INSTRUCTION; + /* + * stval is left zero: the spec allows that for an illegal + * instruction, and only part of the instruction is in hand. + */ + + trap_redirect(&utrap); + + return true; + } + + di->insn_len =3D INSN_LEN(di->insn); + } + + return false; +} + +/* + * Decode the load or store instruction fetched into @di, filling in the + * remaining fields of it (@di->insn and @di->insn_len are filled by + * insn_fetch_faulted()). + * + * @xlen is the effective XLEN of the guest, needed as + * the encodings which exist for XLEN=3D64 only must not be recognized for= a + * 32-bit guest. + * + * Returns false if the instruction is not a load or store which can be + * emulated here. + */ +static __maybe_unused bool decode_ldst_insn(struct decoded_insn *di, + unsigned int xlen) +{ + unsigned long insn =3D di->insn; + /* Register fields of the uncompressed forms ... */ + unsigned int rd =3D RV_RD(insn); + unsigned int rs2 =3D RV_RS2(insn); + /* + * ... and of the compressed ones, where the 3-bit field selects one of + * x8..x15, while the stack-pointer-relative forms have a full-width o= ne. + */ + unsigned int rs2s =3D RVC_RS2S(insn); + unsigned int rs2c =3D RVC_RS2(insn); + + di->is_write =3D false; + di->is_unsigned =3D false; + di->reg =3D rd; + + if ( (insn & INSN_MASK_LB) =3D=3D INSN_MATCH_LB ) + di->len =3D 1; + else if ( (insn & INSN_MASK_LBU) =3D=3D INSN_MATCH_LBU ) + { + di->len =3D 1; + di->is_unsigned =3D true; + } + else if ( (insn & INSN_MASK_LH) =3D=3D INSN_MATCH_LH ) + di->len =3D 2; + else if ( (insn & INSN_MASK_LHU) =3D=3D INSN_MATCH_LHU ) + { + di->len =3D 2; + di->is_unsigned =3D true; + } + else if ( (insn & INSN_MASK_LW) =3D=3D INSN_MATCH_LW ) + di->len =3D 4; + else if ( xlen =3D=3D 64 && (insn & INSN_MASK_LWU) =3D=3D INSN_MATCH_L= WU ) + { + di->len =3D 4; + di->is_unsigned =3D true; + } + else if ( (insn & INSN_MASK_C_LW) =3D=3D INSN_MATCH_C_LW ) + { + di->len =3D 4; + di->reg =3D rs2s; + } + /* c.lwsp and c.ldsp are reserved with rd being x0. */ + else if ( (insn & INSN_MASK_C_LWSP) =3D=3D INSN_MATCH_C_LWSP && rd ) + di->len =3D 4; + else if ( xlen =3D=3D 64 && (insn & INSN_MASK_LD) =3D=3D INSN_MATCH_LD= ) + di->len =3D 8; + else if ( xlen =3D=3D 64 && (insn & INSN_MASK_C_LD) =3D=3D INSN_MATCH_= C_LD ) + { + di->len =3D 8; + di->reg =3D rs2s; + } + else if ( xlen =3D=3D 64 && (insn & INSN_MASK_C_LDSP) =3D=3D INSN_MATC= H_C_LDSP && + rd ) + di->len =3D 8; + else if ( (insn & INSN_MASK_SB) =3D=3D INSN_MATCH_SB ) + { + di->len =3D 1; + di->is_write =3D true; + di->reg =3D rs2; + } + else if ( (insn & INSN_MASK_SH) =3D=3D INSN_MATCH_SH ) + { + di->len =3D 2; + di->is_write =3D true; + di->reg =3D rs2; + } + else if ( (insn & INSN_MASK_SW) =3D=3D INSN_MATCH_SW ) + { + di->len =3D 4; + di->is_write =3D true; + di->reg =3D rs2; + } + else if ( (insn & INSN_MASK_C_SW) =3D=3D INSN_MATCH_C_SW ) + { + di->len =3D 4; + di->is_write =3D true; + di->reg =3D rs2s; + } + else if ( (insn & INSN_MASK_C_SWSP) =3D=3D INSN_MATCH_C_SWSP ) + { + di->len =3D 4; + di->is_write =3D true; + di->reg =3D rs2c; + } + else if ( xlen =3D=3D 64 && (insn & INSN_MASK_SD) =3D=3D INSN_MATCH_SD= ) + { + di->len =3D 8; + di->is_write =3D true; + di->reg =3D rs2; + } + else if ( xlen =3D=3D 64 && (insn & INSN_MASK_C_SD) =3D=3D INSN_MATCH_= C_SD ) + { + di->len =3D 8; + di->is_write =3D true; + di->reg =3D rs2s; + } + else if ( xlen =3D=3D 64 && (insn & INSN_MASK_C_SDSP) =3D=3D INSN_MATC= H_C_SDSP ) + { + di->len =3D 8; + di->is_write =3D true; + di->reg =3D rs2c; + } + else + return false; + + return true; +} + static int emulate_load(const struct guest_fault *gf) { return -EOPNOTSUPP; diff --git a/xen/arch/riscv/include/asm/guest_access.h b/xen/arch/riscv/inc= lude/asm/guest_access.h index 8d679319ded0..39c28dd2ecaa 100644 --- a/xen/arch/riscv/include/asm/guest_access.h +++ b/xen/arch/riscv/include/asm/guest_access.h @@ -5,6 +5,7 @@ #include =20 struct domain; +struct trap_info; =20 unsigned long raw_copy_to_guest(void *to, const void *from, unsigned len); unsigned long raw_copy_from_guest(void *to, const void *from, unsigned len= ); @@ -25,6 +26,9 @@ unsigned long raw_clear_guest(void *to, unsigned int len); unsigned long copy_to_guest_phys(struct domain *d, paddr_t gpa, void *buf, unsigned long len); =20 +unsigned long riscv_read_guest(unsigned long guest_addr, bool read_insn, + struct trap_info *trap); + #endif /* ASM__RISCV__GUEST_ACCESS_H */ /* * Local variables: diff --git a/xen/arch/riscv/include/asm/riscv_encoding.h b/xen/arch/riscv/i= nclude/asm/riscv_encoding.h index b2071f47587c..656a5fcccb0e 100644 --- a/xen/arch/riscv/include/asm/riscv_encoding.h +++ b/xen/arch/riscv/include/asm/riscv_encoding.h @@ -65,6 +65,14 @@ #define SSTATUS64_UXL MSTATUS_UXL #define SSTATUS64_SD MSTATUS64_SD =20 +/* + * Width encoded by the MXL, SXL, UXL and VSXL fields, all of which share = one + * encoding. 0 is reserved. + */ +#define XLEN_FIELD_32 _UL(1) +#define XLEN_FIELD_64 _UL(2) +#define XLEN_FIELD_128 _UL(3) + #if __riscv_xlen =3D=3D 64 #define HSTATUS_VSXL _UL(0x300000000) #define HSTATUS_VSXL_SHIFT 32 @@ -896,6 +904,8 @@ (RV_X(x, 7, 2) << 6)) #define RVC_SDSP_IMM(x) ((RV_X(x, 10, 3) << 3) | \ (RV_X(x, 7, 3) << 6)) +#define RV_RD(insn) RV_X(insn, SH_RD, 5) +#define RV_RS2(insn) RV_X(insn, SH_RS2, 5) #define RVC_RS1S(insn) (8 + RV_X(insn, SH_RD, 3)) #define RVC_RS2S(insn) (8 + RV_X(insn, SH_RS2C, 3)) #define RVC_RS2(insn) RV_X(insn, SH_RS2C, 5) --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844175; cv=none; d=zohomail.com; s=zohoarc; b=F/ibIk7ZMZG4tq7emG40ZhlrxV02TwMJeuL5nAHMWo5Bd5PNkPZ/B6cmnwnCNGhzy2I4wg9zlt1cNJ5Psqi2nkEaSXV//2lRtgx3SCEJH7aoHGp6NRfu7Tv7YhcQ0HwP0FPwfOflL5h2n5/uLgEUuG/55Obhobq0GV9KO9TAQn0= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844175; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=/v2fG+yV7FaiFbgNd6aGxtgxLdiavEOKbrATFwfainU=; b=nAvwSuaEyaFMR3sr3amqgoeMk7P/Kdyom64ldsig8kfIr5UuNXy8inJs5Hm8rA/ihH64JZlJex8SHivnKbf5NBnRsMYXwb2cyM46E0QCSfpy0CM8Qb71lMbDjS5FxF6YKad7Jyprr0YKY5lsDYF37fGzP8xHbScJ5mRXE0mTY68= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844175379573.4171073743353; Thu, 27 Aug 2026 08:22:55 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400977.1636751 (Exim 4.92) (envelope-from ) id 1wzbvv-0005du-5m; Thu, 27 Aug 2026 15:22:27 +0000 Received: by outflank-mailman (output) from mailman id 1400977.1636751; Thu, 27 Aug 2026 15:22:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbvt-0005Yt-Ra; Thu, 27 Aug 2026 15:22:25 +0000 Received: by outflank-mailman (input) for mailman id 1400977; Thu, 27 Aug 2026 15:22:21 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvo-0004S1-Ju for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:20 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvo-009l31-07 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:20 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a905621-2eae-0a2a0a5409dd-0a2a450aa854-18 for ; Thu, 27 Aug 2026 17:22:19 +0200 Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a90562b-f2d2-0a2a450a0019-d1558033ed2a-3 for ; Thu, 27 Aug 2026 17:22:19 +0200 Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-4998b5a63e2so21336015e9.1 for ; Thu, 27 Aug 2026 08:22:19 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:18 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844139; x=1788448939; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=/v2fG+yV7FaiFbgNd6aGxtgxLdiavEOKbrATFwfainU=; b=HX8IG4GYJIEQ0YEUrDgqzhP5H+ruo5EWEPtxixuuPBE4XfyBcXo+5IubYVQELnIjkd VvppDcvxphpnHvJhg/KdsKbC6RBU5OF4122yH8BLOCK55sbmt/trkqItClxGfSPiohcW dZCCUXN9HyrSwnb4EZY1uldQUMJePJ3ayi4Z2D4fDODpvRwp2mCvuYa9CnJUrwBqD56q uznVgdCibGhZKaj+Sl4/K898URBG9bcBODcX/NnMRIDAfkKAg7I6oQ+znrBiBEf9w2QU 5LqWW6DXmNfvdXzyFrbnDPxn81dFvNSDCO5HMoiMWbUHavduQWAAaah2gBhMENjhY9Yk mXIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844139; x=1788448939; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=/v2fG+yV7FaiFbgNd6aGxtgxLdiavEOKbrATFwfainU=; b=L+vjDHW8WTsG3nU/Bazy5C1LdQXjR6nDXb4spD4tF9qXneW/2f9qf5nLqEEYcB2NS8 5FWX1RBPWUbjt/HJsNKxAn7gTQDQEta5YiMbALujS4QaVzDXgNMKUlyM+wEXOsm7Fsx/ yL2hEOxFoUIpmNfF4Cz76jKyHPvgW/VzP3eEgUNTHdkSpd3AL17Ft6x/4yKWwK4WfgM2 j9XJ1M8i61AOvoE0oH0KsRJleeQHYnqiTn7gh40WaqBLOxaXBJsMjx21/ZYKI9vu8YLD p2TiBVPlHjhxlu7qMq7gTX68P3kMduLwK3SOdwVPntoFWokFwKHjVQMwbYnQHVhFhs9z qE0Q== X-Gm-Message-State: AFuF++lNESuja76s0iK2zZsvsLx2H8wDnNnPpolIkGBt+E/49iGIDUA+ aB2mIJVW07zOWVvwCpeiSevubW5IIymn+HBQhedf1j2PMeN6niGLLdmtY0fkMw== X-Gm-Gg: AR+sD12BjaqR1nsgLsnTs8jX+QDaaUkd/wH9gYbE22aAEqXVHE2ASWsMaEGGMDySNu4 Fh7FeXXazcl38uiIj/qYHhrlQbflNfzf3yKp2T3DL0jvpNFqus7/RWWZRRjD3ptM7eJPsjFoMgp 4xS/Bzj0jyA4qxG0Y79uQ2tbBVINh6kiAAdwZORxQy5vDWrCxeSQaHtZ99BtczslidAaZOZNn+J 8EarFUfz0R0a3bGlPxrtrtVH2VD5gRIEKIODI/3moH/xekPQ7P3nBpSkn3ZpcmPVu4Ca2g6/OTg p1EJvNQ/++knNhXdIzW9wklBB0BnfZggiae1HuzZa5dbcNMXlUST4P+EGTdDK0a8HrDlY0Hv6ec ZCLErosoRyJcRYMfgTaN3hM9zgXqN1lqwc6a1fxBSwNrAZRl7lZxUKxH4GGwc1i1Q1lrRjDpCap jyu/8PI+Qav5MdIUV344izkAwR+YHfjALdBmA7CDw0NdRFNgyI/fJVVGBV9j17ZKqF1S5ZztyGW l8SD7lR1N923vuSMLkcUAeWzVvgqoX3 X-Received: by 2002:a05:600c:3f08:b0:499:51f0:a9b2 with SMTP id 5b1f17b1804b1-499dc6ec0e7mr217088315e9.1.1787844139231; Thu, 27 Aug 2026 08:22:19 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 25/39] xen/riscv: add guest load emulation for trapped MMIO accesses Date: Thu, 27 Aug 2026 17:21:09 +0200 Message-ID: <7cf3203f8f826eefa1b24bb2dedbd76c0b611dc1.1787838835.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-4011c0/1787844139-53CD3CFC-BDF5C5AC/10/73395122804 X-purgate-type: spam X-purgate-size: 6912 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844176514158500 Content-Type: text/plain; charset="utf-8" Implement emulate_load() on top of the decoding interface introduced by the previous patch: fetch the trapped instruction, decode it, dispatch the access to a registered MMIO handler via do_mmio(), write the result back into the destination register and step over the instruction. Xen dispatches MMIO synchronously to an in-hypervisor handler, so unlike KVM RISC-V there is no userspace exit/return step and no equivalent of the kvm_io_bus_read() / KVM_EXIT_MMIO / kvm_riscv_vcpu_mmio_return() split; the result is consumed in place. Sign extension is done here rather than in the handlers: a signed load is normalized by a shift pair, so a handler need only report the value it read. At the moment vINTC is the only backend registered with the MMIO dispatch, so in practice this only covers vINTC traps. An access which no handler claims currently crashes the domain; injecting an access fault into the guest instead is left for later. Signed-off-by: Oleksii Kurochko --- Changes in v2: - Move the emulation code to the new arch/riscv/emulate.c, leaving traps.c with trap dispatch only. - Split the patch up: struct decoded_insn and the decoding helpers are introduced by "xen/riscv: introduce the interface for trapped instruction decoding" and filled in by "xen/riscv: implement trapped instruction decoding", so only emulate_load() itself is left here. - do_mmio() is no longer defined alongside emulate_load(); it now lives in mmio.c, next to the dispatch it drives. - Don't write the result of a load into x0. SET_RD() wrote rd unconditionally, so a load into x0 clobbered regs->zero and broke the invariant that it reads as zero when x0 is a source operand elsewhere. - Recognize the XLEN=3D64-only encodings by the guest's effective XLEN (guest_xlen()) rather than by Xen's own (CONFIG_RISCV_32). Besides those encodings simply being reserved on RV32, the compressed ones are ambiguo= us there: C.LD and C.FLW share the encoding 0x6000 (mask 0xe003), and likew= ise C.SD/C.FSW, C.LDSP/C.FLWSP and C.SDSP/C.FSWSP. - Take the faulting address from struct guest_fault, filled in by resolve_faulting_gpa(), rather than from get_faulting_gpa(). - Drop the description of a fault taken while re-reading the trapped instruction: that code is now in the patch implementing fetch_trapped_insn(), where a G-stage fault is reported to the guest as CAUSE_FETCH_ACCESS instead of hitting a BUG_ON(). - Update the commit message accordingly. --- --- xen/arch/riscv/emulate.c | 53 +++++++++++++++++++++++++++++++--------- 1 file changed, 42 insertions(+), 11 deletions(-) diff --git a/xen/arch/riscv/emulate.c b/xen/arch/riscv/emulate.c index 81a50643a5ec..e52f2851800c 100644 --- a/xen/arch/riscv/emulate.c +++ b/xen/arch/riscv/emulate.c @@ -5,7 +5,6 @@ */ =20 #include -#include #include #include #include @@ -15,6 +14,7 @@ #include #include #include +#include #include #include #include @@ -65,8 +65,7 @@ static bool is_load_guest_page_fault(unsigned long scause) return scause =3D=3D CAUSE_LOAD_GUEST_PAGE_FAULT; } =20 -static __maybe_unused void advance_pc(struct cpu_user_regs *regs, - unsigned int step) +static void advance_pc(struct cpu_user_regs *regs, unsigned int step) { regs->sepc +=3D step; } @@ -88,7 +87,7 @@ static __maybe_unused void advance_pc(struct cpu_user_reg= s *regs, * IS_ENABLED() can't be used here as HSTATUS_VSXL is defined for * __riscv_xlen =3D=3D 64 only, the field not existing on RV32 in the firs= t place. */ -static __maybe_unused unsigned int guest_xlen(const struct cpu_user_regs *= regs) +static unsigned int guest_xlen(const struct cpu_user_regs *regs) { #ifdef CONFIG_RISCV_32 return 32; @@ -179,8 +178,7 @@ static void resolve_faulting_gpa(struct guest_fault *gf) * Relies on x0..x31 being laid out at the start of struct cpu_user_regs in * architectural register-number order; see the comment there. */ -static __maybe_unused unsigned long *guest_gpr(struct cpu_user_regs *regs, - unsigned int reg) +static unsigned long *guest_gpr(struct cpu_user_regs *regs, unsigned int r= eg) { ASSERT(reg < 32); =20 @@ -197,8 +195,8 @@ static __maybe_unused unsigned long *guest_gpr(struct c= pu_user_regs *regs, * caller to do. Where it returns false, @di has been filled in and emulat= ion * is to continue. */ -static bool __maybe_unused insn_fetch_faulted(const struct guest_fault *gf, - struct decoded_insn *di) +static bool insn_fetch_faulted(const struct guest_fault *gf, + struct decoded_insn *di) { unsigned long htinst =3D gf->htinst; =20 @@ -306,8 +304,7 @@ static bool __maybe_unused insn_fetch_faulted(const str= uct guest_fault *gf, * Returns false if the instruction is not a load or store which can be * emulated here. */ -static __maybe_unused bool decode_ldst_insn(struct decoded_insn *di, - unsigned int xlen) +static bool decode_ldst_insn(struct decoded_insn *di, unsigned int xlen) { unsigned long insn =3D di->insn; /* Register fields of the uncompressed forms ... */ @@ -419,7 +416,41 @@ static __maybe_unused bool decode_ldst_insn(struct dec= oded_insn *di, =20 static int emulate_load(const struct guest_fault *gf) { - return -EOPNOTSUPP; + struct cpu_user_regs *regs =3D gf->regs; + mmio_info_t info =3D { .is_write =3D false }; + struct decoded_insn di; + unsigned int shift =3D 0; + int rc; + + /* A fault taken re-reading the instruction is redirected to the guest= . */ + if ( insn_fetch_faulted(gf, &di) ) + return 0; + + if ( !decode_ldst_insn(&di, guest_xlen(regs)) || di.is_write ) + return -EOPNOTSUPP; + + if ( !di.is_unsigned ) + shift =3D BITS_PER_BYTE * (sizeof(unsigned long) - di.len); + +#ifdef EMULATE_LOAD_DEBUG + gdprintk(XENLOG_DEBUG, "pc=3D%#lx, addr=3D%#"PRIpaddr", len=3D%u, shif= t=3D%u\n", + regs->sepc, gf->gpa, di.len, shift); +#endif + + rc =3D do_mmio(&info, gf->gpa, di.len); + if ( rc ) + return rc; + + /* + * A load into x0 discards its result: writing regs->zero would break = the + * invariant that it reads as zero when x0 is a source operand elsewhe= re. + */ + if ( di.reg ) + *guest_gpr(regs, di.reg) =3D (long)(info.data << shift) >> shift; + + advance_pc(regs, di.insn_len); + + return 0; } =20 static int emulate_store(struct guest_fault *gf) --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844169; cv=none; d=zohomail.com; s=zohoarc; b=iUwXM6yaKTTRv7kFINKLHsaNRtjkGWomIyWghn+oDHMREJIpYz+RcFf1JegAPC9VGPadZuUdUu+ljR/1bWNWWxDEf5bF8pg9VkToyBCnEOYoWnBM0UpPanFIfEkhkksGoyl7Q4KhnaYm/pPo0Bz9zktlynJne2NUEO37d733NMg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844169; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=gZTx0bU/mxPx7+QJKNbysv2gyLTB7dXlROpqZD5enjk=; b=dWnWPDN+6eB9IcCVzvlPhAv8gOp0lYiRZQHxJLHoYNDwG8tEh4wviVw9vNkDqEPwqWij0ffyZt+6S80y4pnf+LroSPQEVcs4nNvGbVBYjJuyd4OUGYB7xrLG0UTOqFGiIBkvgYvsYAl3XgjeLbltE480t60Jm+ujyNDjiGB/8/o= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844169074921.7682034351488; Thu, 27 Aug 2026 08:22:49 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400980.1636756 (Exim 4.92) (envelope-from ) id 1wzbvw-0005yd-IO; Thu, 27 Aug 2026 15:22:28 +0000 Received: by outflank-mailman (output) from mailman id 1400980.1636756; Thu, 27 Aug 2026 15:22:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbvv-0005qz-K9; Thu, 27 Aug 2026 15:22:27 +0000 Received: by outflank-mailman (input) for mailman id 1400980; Thu, 27 Aug 2026 15:22:22 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvp-0004kh-UY for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:22 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvp-009l31-BL for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:21 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a90561e-2eae-0a2a0a5409dd-0a2a4502cbb6-26 for ; Thu, 27 Aug 2026 17:22:21 +0200 Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a90562d-6ca4-0a2a45020019-d155802ba522-3 for ; Thu, 27 Aug 2026 17:22:21 +0200 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-495437bb891so9120685e9.1 for ; Thu, 27 Aug 2026 08:22:21 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:20 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844141; x=1788448941; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=gZTx0bU/mxPx7+QJKNbysv2gyLTB7dXlROpqZD5enjk=; b=irp2F9COsNkbkn4NZq1MISTqByYcnrJOFSOrdAuxwLPlOsw1CGsTS+7l/gC1UGS1gp rDxNPuM1+x7UrnRb/o2Tc7B9bXy86efQFTGimScIs/RaySsw4RotCgTF7auu9iVM/ksP G55U9mpCsi5z4nH8P1Da47NvwKVXrL6n/ooD9M4ySCCbMlQjDvV0WMuIwVz4S43MR4vm UEKMqz4mA+Bs6uPj0+ge1ZRGjV9CDyv60LGw9iseADzxcIE75zCyEvmCUj7brPVdlM09 Qmg2HHlrURF3U4mL3/auhAiRJldhFxGT6LQpjeen3vzS3OW/IPGeabGW0WZb2FkzONzM MtMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844141; x=1788448941; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=gZTx0bU/mxPx7+QJKNbysv2gyLTB7dXlROpqZD5enjk=; b=bGFcH9e9JlelUDF6w6AsSRORNOgEp+W+n4gMyCaLwelRsvPZvyIVgERGPDHMMD3fy0 CccZWhNry8N8hUKC4tPqzFYaVM0DD+Z8KY1FLJA2LFfKd/ThjZ+AvZFlH+yFos8jWBXS be5HJRjZq/ar2LjIRRQbO4IMBN15d5epnmeMdHJ92erGrwOA8jq7bQJZYcBSLGoXy5H9 h8fQyGsx/+bQW6/1csoG6n0q6wwNJTyR9zNSBihR2Boytkm6c1GVpltE/x8FdvjRQqIH uFs/kn9hmhEKIJn90P5NiiBpWTxDAjTSz+yklb5agVt4j9d45KpZ45OkMitGIAjOC4ou Uc7g== X-Gm-Message-State: AFuF++nk0ijN9X3xs5loldPziJgrPNvfJn2ICJfVaRuULNQ6WONclt+N +YndU8WdlzscburdoD1306FhCm2YSr02gWJUf0I2nEqWb9pzXLV8QQcETPQXuQ== X-Gm-Gg: AR+sD11ddQGdJGBcZPVRw7LyN5MSOV5SfkDBh8QXDvjaTUYK5Gc905+hT8VvTaI4i3i 15ON3ThciRcNJiJIjkYgNJ6bVsfhsxohGFTZfPXEZe/D3Hf4MkT/BTB2dztcrHtsmVf/UtAD92M Wpj0G8tTH3Fa5WelLP3ImQN+aJkO6oQeJEeOaKNkDro8PyxYY1HJAhWzKgDRLvEqkkw8kJhMoPe 3jiO2OZwGAR9c+uIe3LRyvKNS6xtgoESnXECGwJwXnB6fn2EAIvkfNq82tawLrdQKe66+Hp0EFV TMZexOlfsto2RS+qfUP3nW2YDFgAM9Uq6j9LFheTdFz8RIT9Sody2M9ZmLDxGmPrxpfZb2Tw242 6rsnCWpug8bAKVspYA72RAbgYnr0yWnL7bD/8tTcHzNppkkKa8XXh2AHmcx6orjMlELlybbFw72 Qyd9PwcsbmqZHRl2MMXkbxE3Px5g7cNmU+r0vVfdyVwn4PE7Gd03HGfBlPkKyqAG18M4wAuK5G7 Rfol6OQxU1YZcWi+7/R8dyak+THpjqU X-Received: by 2002:a05:600c:138e:b0:49a:ce8f:1a5e with SMTP id 5b1f17b1804b1-49b0dea94a8mr80611035e9.2.1787844140654; Thu, 27 Aug 2026 08:22:20 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 26/39] xen/riscv: add guest store emulation for trapped MMIO accesses Date: Thu, 27 Aug 2026 17:21:10 +0200 Message-ID: <230c35550edff0b2b8480b6728614305951fe5cd.1787838835.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-720697/1787844141-F12A12AC-FF43D5A4/10/73395122804 X-purgate-type: spam X-purgate-size: 3716 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844170430158500 Content-Type: text/plain; charset="utf-8" Extend the guest page fault handler with store emulation to support MMIO write accesses. The instruction decode mirrors emulate_load() and, like it, is adapted from Linux's KVM RISC-V implementation. As with the load path, the completion is synchronous through try_handle_mmio() rather than KVM's userspace exit/return split, since Xen's MMIO handlers run in the hypervisor. Faults taken while re-reading the trapped instruction are handled by decode_ldst_insn(), shared with the load path. When a guest store instruction faults, the trapped instruction is decoded using HTINST or, if unavailable, fetched via unprivileged access. At the moment only virtual interrupt controller (vINTC) traps are expected to occur, since it is currently the only backend registered with the MMIO handler dispatch, so in practice the store is emulated via the vINTC backend. Together with load emulation, this completes the basic MMIO handling path needed for virtual interrupt controller support on RISC-V. Signed-off-by: Oleksii Kurochko --- Changes in v2: - Move the emulation code to the new arch/riscv/emulate.c, leaving traps.c with trap dispatch only. - Split the patch up: the instruction fetch and the mask/match chain now live in "xen/riscv: add helpers for decoding a trapped load or store" (struct decoded_insn, insn_fetch_faulted(), decode_ldst_insn(), guest_gpr(), advance_pc()), so only emulate_store() itself is left here. - Since the decoder is now shared with the load path, reject an encoding which is not a store (!di.is_write) explicitly; in v2 the mask/match chain was store-only and could not match a load. - Recognize the XLEN=3D64-only encodings by the guest's effective XLEN (guest_xlen()) rather than by Xen's own (CONFIG_RISCV_32). Besides those encodings simply being reserved on RV32, the compressed ones are ambiguo= us there: C.SD and C.FSW share an encoding, and likewise C.SDSP and C.FSWSP. - Read the source register through guest_gpr() instead of the GET_RS2()/GET_RS2S()/GET_RS2C() macros; which of the three register fields an encoding names is now decided by decode_ldst_insn(). - Take the faulting address from struct guest_fault, filled in by resolve_faulting_gpa(), rather than from the fault_addr parameter. - Drop the description of a fault taken while re-reading the trapped instruction: that code is now in the patch adding the decoding helpers, where a G-stage fault is reported to the guest as CAUSE_FETCH_ACCESS. - Update the commit message accordingly. --- --- xen/arch/riscv/emulate.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-) diff --git a/xen/arch/riscv/emulate.c b/xen/arch/riscv/emulate.c index e52f2851800c..1535b843525e 100644 --- a/xen/arch/riscv/emulate.c +++ b/xen/arch/riscv/emulate.c @@ -453,9 +453,28 @@ static int emulate_load(const struct guest_fault *gf) return 0; } =20 -static int emulate_store(struct guest_fault *gf) +static int emulate_store(const struct guest_fault *gf) { - return -EOPNOTSUPP; + struct cpu_user_regs *regs =3D gf->regs; + mmio_info_t info =3D { .is_write =3D true }; + struct decoded_insn di; + int rc; + + if ( insn_fetch_faulted(gf, &di) ) + return 0; + + if ( !decode_ldst_insn(&di, guest_xlen(regs)) || !di.is_write ) + return -EOPNOTSUPP; + + info.data =3D *guest_gpr(regs, di.reg); + + rc =3D do_mmio(&info, gf->gpa, di.len); + if ( rc ) + return rc; + + advance_pc(regs, di.insn_len); + + return 0; } =20 static void inject_access_fault(const struct guest_fault *gf) --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844175; cv=none; d=zohomail.com; s=zohoarc; b=TuLmOq53tBp41e+r5252XXSFMEFcps6RD9vdFLasUvjpji554RE5BgxXAA9LFW/sBavBE+uZ0BEDVvGs1mpkd8YL2Qfx0hsoZoRIWl+UzSC7rQo4YBlu26xO/N5syz2JgoftbEAHszCjWZo4fTu9JUoJzeKQ/4Ytv3UxKnuqKE8= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844175; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=NbUDvsGLg78NddOCawoOaUli56hcmNzHbJnJ/eb+qqM=; b=DbEzJ5gVW+TpChSYQfJASMnkPVaj3/fgeAOhSoRcuwPr3U3Tobm5kSt+Wrrd4WcEyZj9ydIPJ1FwwX2Xwek+qiURrYNWFkZ+59xD6TnXn9DHxF2u/8rk/o0DTW9P+qA++eve5Cz5MD/8QQO7k2yy7jQWbwUsTkAOKQNSwT+TiZ8= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 178784417561375.91726021688908; Thu, 27 Aug 2026 08:22:55 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400987.1636764 (Exim 4.92) (envelope-from ) id 1wzbvy-0006D5-7B; Thu, 27 Aug 2026 15:22:30 +0000 Received: by outflank-mailman (output) from mailman id 1400987.1636764; Thu, 27 Aug 2026 15:22:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbvx-00068R-6Q; Thu, 27 Aug 2026 15:22:29 +0000 Received: by outflank-mailman (input) for mailman id 1400987; Thu, 27 Aug 2026 15:22:23 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvr-000523-7h for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:23 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvq-00C7F4-JT for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:22 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a90562c-e002-0a2a0a5209dd-0a2a4505e5e4-4 for ; Thu, 27 Aug 2026 17:22:22 +0200 Received: from [209.85.128.51] (helo=mail-wm1-f51.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a90562e-4cb1-0a2a45050019-d1558033b90c-3 for ; Thu, 27 Aug 2026 17:22:22 +0200 Received: by mail-wm1-f51.google.com with SMTP id 5b1f17b1804b1-499b2981a7bso9943945e9.3 for ; Thu, 27 Aug 2026 08:22:22 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:21 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844142; x=1788448942; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=NbUDvsGLg78NddOCawoOaUli56hcmNzHbJnJ/eb+qqM=; b=MZ7uBruKJkJV7cwslMDci3jqcDi0ku1svcuUoRtCs08kCJOhBXyHYADQRcr6xeDPoN h9l11Jdrnt8q3SOoQVIBexjLqv2rXNejarY92N6TmdMltwREd02BFqUlY/7M5UP6OGP4 IgopEKWZivmSZ/5TAVCUSDqHladNsSPURmiXasB55o2ao1G77Ww1JXd7+hZuP02oay4g wlx1pnoV7vPzk2pvAMUgI/xVxVgAo2oinpahbO9WbuIUqKkEt5u2c2TgunTiZqzrE3C9 HZMTMcwNOte3lfKiGdXbp9ZRTEfYfbRELuvs5Dy9EDcSVwb7kJjWl+6j15yf6+jq/psQ jKyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844142; x=1788448942; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=NbUDvsGLg78NddOCawoOaUli56hcmNzHbJnJ/eb+qqM=; b=MwzO4kHOZbEpEAsemTCQjwBbryrSc2ncGhG2mTLyoWRxubwXcCPgb3XcCXGexhu0U1 y5EOpn2HqnqhU+DC/nD6H8ruRfXP+4PTHQIujYTSPadSqcqbKG0gOCNi0lD9cIDYewBl VYBdihVbItubjo0Y4p+kQKwWAIqfJfBhbppCOwOnoGVI4s6uyDjQI84+0ezIrI+sLMiB hMDmDuex8y8D7J0iwsJPqViwuCnJYUXmJ/xv1EnTGQnAlYyLprgEZtSG2MuCB34HKfF4 PYaYn50202f1zGXmOk5vDqf5Zc2V7VCvoZPNUFLqZZjSdhvgB4GyscD6IjLxHUZAopnp 7I0w== X-Gm-Message-State: AFuF++lH6AfKYhL+mHmj/j7nN/v0VNca4Yaf1RwvLaRLkMdBDAOKfVXG 2MjzmCkabWL0dt8wxHWy1cWcC44qChYJZzJhidMC51hFE7Sf+hIxli89vCzXLw== X-Gm-Gg: AR+sD12CHx8e8bHuzS33HJnn7fhvDFHuczigpO/aI6RlYl5oUigK/rgBWoazGViATYY iuvSRvagV1R0O2po4nV9eAuBLP9OYpm27JONX7TnITFmrNzUTEx1hr/3uTm/8bt22CY9ghgfepC tNyVq/okA6eiLUgTZUR1cxas/d6EDeip9maaUDIiVLIjI0uZrNjrWIOL/D7cUh+8yoS5UdCLYrc oFGOu7ZRHLTHpHYvuLtd92ZDmX2f3mSWZMH3OSQJkt0aXhk0Iu7uBLY1x239+VmToZwWs8ZawSP a5ds/7EkIZJ7SRBVeRwqAgyPFc/JZ25jMQJ8siUF5QZufHXKli/Rfjtt+Oanc5Iuq9AqOyY6KlL t5Yrfqt7tyGDkcfIGXKG3ij3nNm+NQfNXe9Koqihtsta00BRdLy6KLP6F1EU5cJZdyd7xDGCO7B hZRbIczDRu3WHLT5wCVQCDhyOE51DMad4/OK3et9+NlR0BwDJISCieVJD8MS4+hCuAu8XZHeTt5 SNG4uFWUG1D/4l2aaTjo2rj8JSXLEoQ X-Received: by 2002:a05:600c:6088:b0:499:a277:e8b5 with SMTP id 5b1f17b1804b1-499dc6f3248mr202823325e9.3.1787844141903; Thu, 27 Aug 2026 08:22:21 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 27/39] xen/riscv: introduce arch_move_irqs() Date: Thu, 27 Aug 2026 17:21:11 +0200 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-c201ff/1787844142-251182A1-AA301120/10/73395122804 X-purgate-type: spam X-purgate-size: 4235 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844176462158500 Content-Type: text/plain; charset="utf-8" When migrating a vCPU between pCPUs the hypervisor must also migrate the associated virtual interrupt state. arch_move_irqs() is the per-arch hook called by generic code to trigger that. Replace the static inline BUG_ON placeholder in asm/irq.h with a real implementation in intc.c dispatching through a new move_irqs vintc_ops callback. Wire it up in vAPLIC, which delegates to imsic_migrate_vcpu() which itself still a stub to be implemented in follow-up patches. Note that technically ASSERT() in arch_move_irqs() could be skipped as it will be anyway NULL pointer dereference (and a trap will occur) if something isn't properly initialized but sometimes it is harder to find place where NULL pointer derefence happened as it isn't guaraunted that all necessary registers will be filled with something useful. As at the moment I don't find any case when ->move_irqs() could be skipped, the check that ->move_irq isn't NULL is added to ASSERT() instead of adding "if ( ...->move_irq) vitnc->ops->move_irqs(v)". Signed-off-by: Oleksii Kurochko --- Changes in v2: - New patch. --- --- xen/arch/riscv/imsic.c | 5 +++++ xen/arch/riscv/include/asm/imsic.h | 2 ++ xen/arch/riscv/include/asm/intc.h | 3 +++ xen/arch/riscv/include/asm/irq.h | 5 +---- xen/arch/riscv/intc.c | 8 ++++++++ xen/arch/riscv/vaplic.c | 1 + 6 files changed, 20 insertions(+), 4 deletions(-) diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c index 3787f270d8e3..b0c4a9e2d728 100644 --- a/xen/arch/riscv/imsic.c +++ b/xen/arch/riscv/imsic.c @@ -686,3 +686,8 @@ int __init vimsic_make_domu_dt_node(struct kernel_info = *kinfo, =20 return fdt_end_node(fdt); } + +void imsic_migrate_vcpu(struct vcpu *v) +{ + BUG_ON("unimplemented"); +} diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/as= m/imsic.h index 73129c3c9ea7..57d8c729ac0d 100644 --- a/xen/arch/riscv/include/asm/imsic.h +++ b/xen/arch/riscv/include/asm/imsic.h @@ -112,4 +112,6 @@ int vimsic_make_domu_dt_node(struct kernel_info *kinfo,= unsigned int *phandle); void imsic_ctxt_switch_from(struct vcpu *v); void imsic_ctxt_switch_to(struct vcpu *v); =20 +void imsic_migrate_vcpu(struct vcpu *v); + #endif /* ASM_RISCV_IMSIC_H */ diff --git a/xen/arch/riscv/include/asm/intc.h b/xen/arch/riscv/include/asm= /intc.h index 62e1410156c7..b5ab39aa2b39 100644 --- a/xen/arch/riscv/include/asm/intc.h +++ b/xen/arch/riscv/include/asm/intc.h @@ -70,6 +70,9 @@ struct vintc_ops { =20 /* Restore vINTC state of the vCPU being switched in */ void (*ctxt_switch_to)(struct vcpu *v); + + /* Move interrupts of vCPU to a different pCPU */ + void (*move_irqs)(struct vcpu *v); }; =20 struct vintc { diff --git a/xen/arch/riscv/include/asm/irq.h b/xen/arch/riscv/include/asm/= irq.h index 66067747dc0f..314b8ee0e00c 100644 --- a/xen/arch/riscv/include/asm/irq.h +++ b/xen/arch/riscv/include/asm/irq.h @@ -41,10 +41,7 @@ struct irq_desc *irq_to_desc(unsigned int irq); struct cpu_user_regs; struct dt_device_node; =20 -static inline void arch_move_irqs(struct vcpu *v) -{ - BUG_ON("unimplemented"); -} +void arch_move_irqs(struct vcpu *v); =20 int platform_get_irq(const struct dt_device_node *device, int index); =20 diff --git a/xen/arch/riscv/intc.c b/xen/arch/riscv/intc.c index 9fff501b9c25..b3a16ae9be67 100644 --- a/xen/arch/riscv/intc.c +++ b/xen/arch/riscv/intc.c @@ -192,3 +192,11 @@ void vintc_ctxt_switch_to(struct vcpu *v) =20 ops->ctxt_switch_to(v); } + +/* Move vCPU's IRQs from one pCPU to another */ +void arch_move_irqs(struct vcpu *v) +{ + const struct vintc_ops *ops =3D v->domain->arch.vintc->ops; + + ops->move_irqs(v); +} diff --git a/xen/arch/riscv/vaplic.c b/xen/arch/riscv/vaplic.c index 6c60fe2baf0c..0c75ba2fb2fe 100644 --- a/xen/arch/riscv/vaplic.c +++ b/xen/arch/riscv/vaplic.c @@ -429,6 +429,7 @@ static const struct vintc_ops vintc_ops =3D { */ .ctxt_switch_from =3D imsic_ctxt_switch_from, .ctxt_switch_to =3D imsic_ctxt_switch_to, + .move_irqs =3D imsic_migrate_vcpu, }; =20 int domain_vaplic_init(struct domain *d) --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844171; cv=none; d=zohomail.com; s=zohoarc; b=IhNo5P470FZsA8LKQOTnhmpL31csdF24h8BgjHbSykLoTb/lUMmTFB954q0oTFIZGjwCMLSSM5fknCLkKjDnQ4errd0lzOueemy5QcIi3OI+PavG/oJvTgjl+S2tNkIrvg2gEbSmtckwPkvRFYXbsc7z5+d3SKzsfhTgkcVS3TA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844171; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=7ldkqFQjndFbNw/I9T05JUW6mqsTU4X6qRLWNgFjU/Y=; b=ZA4SB4urftKz/5P0zmSxFVKa76LeINIv/PpEyH31E0UGdUUpw3uV9gW7YfgkmmJMJZRdtTi6HPsAEo7Zuxi4BLE3KrBL+mZhXgu06RSjaBntOsk5GzYrhXHTTw9qnu9Cy3QxNDxNz3t3FQ28l1COmIz4NGu2Zra3D942MvJIDP4= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844171410417.60974833946455; Thu, 27 Aug 2026 08:22:51 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400990.1636772 (Exim 4.92) (envelope-from ) id 1wzbw1-0006ns-0f; Thu, 27 Aug 2026 15:22:33 +0000 Received: by outflank-mailman (output) from mailman id 1400990.1636772; Thu, 27 Aug 2026 15:22:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbw0-0006h8-46; Thu, 27 Aug 2026 15:22:32 +0000 Received: by outflank-mailman (input) for mailman id 1400990; Thu, 27 Aug 2026 15:22:25 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvs-0005Hc-EX for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:24 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvr-00C7F4-Pr for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:23 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a90562c-e002-0a2a0a5209dd-0a2a4505e5e4-6 for ; Thu, 27 Aug 2026 17:22:23 +0200 Received: from [209.85.221.53] (helo=mail-wr1-f53.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a90562f-4cb1-0a2a45050019-d155dd35c0ad-3 for ; Thu, 27 Aug 2026 17:22:23 +0200 Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-480001972b8so454855f8f.2 for ; Thu, 27 Aug 2026 08:22:23 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:22 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844143; x=1788448943; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=7ldkqFQjndFbNw/I9T05JUW6mqsTU4X6qRLWNgFjU/Y=; b=MsEJwDeXQ9PUqJmqj7nd9UqEW9/ZnxdTCo3euYydnLkqn5w+I8I4TYjRLC5VHL73t9 0pno9VFf0bMeIXmLDeadhgX1PBRF3vFYufgiToYDt1eWRqOnsKiVePy6bekDgS92zLhM ONq9F6hLbaojmGpcoaSsVttt9md0CYzTP41sSbYOGKaAgyAZvmjmJ8/7jgbn+iTCgNqG aJtM5uD3GK0uXk7DBqjoNlubUdDmX26r6W9Q6hrUuQEfhRMDd0MYV/GX97zSWYgOibvR Hoco9YXQdKR1Cbwe4A0l/r2IgCnd6guUJh6LC+vgHiToif4QIdzVBZ4FtamvK8RY/dU0 X7UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844143; x=1788448943; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=7ldkqFQjndFbNw/I9T05JUW6mqsTU4X6qRLWNgFjU/Y=; b=rxezR4t8+qrlUiBvYxEkiKLEJKyN3c7M5oflKDqxBVyn2xbBpMJfZB5qprx/MkOJsF PMZvFyH7NymDpF8eAmQLYiUzeZCqQExe/Ms/bEoK5cXZh2bR5EeWpa+dnqZxdibLkjfT 2EqQiC/ckqAnpU7wkNYA4bx8hYg3c8HKivpgZiSQJiubuQyL6hfyf738TnRxRiz2+X8a UUBatLaJ/JLQj5nwWSH20Vhtn3D3Lb9HrdyWtfm8MBnIalLq9cGcUh2b2b3aHtFjN9uu f2lGeXdrQVHXRGQG2K1YXiJgBLj19qZby+8zikoDm8SuJzxUzbOfSlDnHqFgWSz/BfGB sxtg== X-Gm-Message-State: AFuF++nREAsPmDSkdcOBk2gfVF8yx48CI8mQy5kL7fdvtEK6eYrfHlwu q0/rrUKORkCP4yLeC+4iLhNs302d4PhWxC2LaxrcCjV9TsVnnwHpeQ0mXpuU/Q== X-Gm-Gg: AR+sD12uitjBgfUc+gJA9ql4MPQEoEbuaDz3q0qqwLOM9G90wVJ2us74U38GWyvaF/e iMjEhTYqvvvWszvwI7XiVZst3k5Sr++aMPtv0v0bLwX5fBZOTfjnNI9QylZ5xEKrAgH8kXVV/UG Ew+HDK+kvNLzvFXNNV8z+adA4C7WYl2S8h9M0srlm2IFuFkrDKri+xdN+xOeL8tvJlkgYX+M9om qXQVuAMr5S8xgqRYZmRKKci5SnCmAKsCqLCbIU+7o55hkp+6v8NMUZcu4cGtGQQAw+hQUGXAG0I fOmiw4SuKZEIKaYKq0rGcbaRXbYfu5e3EqSjO1X7+sd6V0DgnqvCBXNRVjw+K/kU7kLnBAt17aj zZoxpTlGf7EWXRrAzMy+eYGqoV2hK9Gi3sQApYvc4x6LnYup0dPjnxdXrkSVrxhkj2OMi5tzpR/ fs6vZILom10g44l/OszJvBPDMEPl/yqlmAHSvigZc9KbgU589VDNWMm6Kj57Ow7rUtJmAvkBx2q w7AZl0B4zwU/psIgpXbL96H7g+JMJpo X-Received: by 2002:a05:600c:4712:b0:495:6e68:5df2 with SMTP id 5b1f17b1804b1-499dc7260e5mr180627895e9.12.1787844143153; Thu, 27 Aug 2026 08:22:23 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 28/39] xen/riscv: handle the case when no vCPU migration is needed Date: Thu, 27 Aug 2026 17:21:12 +0200 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-c201ff/1787844143-F62AB2A1-B7CCD5AB/10/73395122804 X-purgate-type: spam X-purgate-size: 1447 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844172382158500 Content-Type: text/plain; charset="utf-8" The IMSIC vsfile mapping is performed in continue_new_vcpu(), since the target pCPU must be known at that point. It is therefore possible for imsic_migrate_vcpu() to be called before continue_new_vcpu() has executed, in which case v->arch.last_pcpu is NR_CPUS and there is nothing to migrate. Add a BUG_ON("unimplemented") placeholder in imsic_migrate_vcpu() to guard against silent incorrect behaviour or unexpected panics in guest VMs until the function is fully implemented. Signed-off-by: Oleksii Kurochko --- Changes in v2: - New patch. --- --- xen/arch/riscv/imsic.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c index b0c4a9e2d728..ad7fbe708bfd 100644 --- a/xen/arch/riscv/imsic.c +++ b/xen/arch/riscv/imsic.c @@ -689,5 +689,15 @@ int __init vimsic_make_domu_dt_node(struct kernel_info= *kinfo, =20 void imsic_migrate_vcpu(struct vcpu *v) { + /* + * The scheduler can mark a freshly created vCPU's unit as migrated and + * invoke this before the vCPU has ever run (see the migrated branch in + * schedule()). No need to do migration for such vCPUs as they aren't = fully + * initialized (for example, context_switch() will be called after + * imsic_migrate_vcpu()). + */ + if ( v->arch.last_cpu =3D=3D NR_CPUS ) + return; + BUG_ON("unimplemented"); } --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844183; cv=none; d=zohomail.com; s=zohoarc; b=J31BJgQHxWXrD01foN5OHxyShpZ+gj2RYTvxdYRYyWQ2FYeysillF0r77yJyilZkH1RN4Ew135I6C+kxyDpxiWdcwRFSv+fBJsQzVEz75Oxa7QWv7L1LIEhTeSaX3ktVR/VsoMaS4xvk5+BT+T+smQ6uZXLjDRUwIhwyuzoxunI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844183; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=EO1Ejgjh8QKw8eND0v67zM6XR+OCktbAr5444WUjCzU=; b=nU7EukWy5Mb09yphLrsO5t09j3yyJaHBqZc77o5bR5e/t9dgAZX9YxCo3M22iMMDToG/rH97D5W1mwYmK8kC5xPgurxw5ghBNdgV9CYi0HTvVtQQun1Tci+2Enj3enankjg+E6JWpjdGHw3Mp4lGssvHJcfFTouKZ9WoSskIzvs= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844183218405.9125897729099; Thu, 27 Aug 2026 08:23:03 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1400999.1636782 (Exim 4.92) (envelope-from ) id 1wzbw3-0007BO-8s; Thu, 27 Aug 2026 15:22:35 +0000 Received: by outflank-mailman (output) from mailman id 1400999.1636782; Thu, 27 Aug 2026 15:22:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbw1-00077w-Oh; Thu, 27 Aug 2026 15:22:33 +0000 Received: by outflank-mailman (input) for mailman id 1400999; Thu, 27 Aug 2026 15:22:27 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvu-0005cy-CM for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:26 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvt-009l31-N4 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:25 +0200 Received: from [10.42.69.10] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a905621-2eae-0a2a0a5409dd-0a2a450aa854-32 for ; Thu, 27 Aug 2026 17:22:25 +0200 Received: from [209.85.128.43] (helo=mail-wm1-f43.google.com) by tlsNG-4011c0.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a905631-f2d2-0a2a450a0019-d155802bc51e-3 for ; Thu, 27 Aug 2026 17:22:25 +0200 Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-49b8ce9b733so6304285e9.1 for ; Thu, 27 Aug 2026 08:22:25 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:24 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844145; x=1788448945; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=EO1Ejgjh8QKw8eND0v67zM6XR+OCktbAr5444WUjCzU=; b=eX9TupMYkkwd1S5hj0axk4capGcfTbriEGYblcLUmOia0XcE1WcUB/1uCtdkWf5aX5 o2BY097AVb/MTUgsVXR3BzqANy7yZJ8yamSu2EqS0BDTwfOw4EFNqb4EKO/KMQSkfhEK JbK21SxsWXIDGphCp8fnM4GbvlSG93jR6/+WHdCssG8CTvlsKKhM2EV01Ay+Pa/BIzQm VuZmk6L7i96cZcwI0S2jTO8ir0ms/lt5qSO5jfzVq1D+P4niqTx666u2unJ3Xh6r753b AsYNbG5NGJ3yFgyYYh186TR9sBIpcjHxe7u99Ig7hUO20KsjvTh+GMEYK22h6idGZK0h nNfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844145; x=1788448945; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=EO1Ejgjh8QKw8eND0v67zM6XR+OCktbAr5444WUjCzU=; b=lE/YjgK5fNY1agNq5k249yXz4EXUxyWsr9f2DlhVP5ej8RHqvHEOERefa099yLi8oo Boe7ZbTNN8LeJ9/8cRzj4rBo82tHLPTiLyMlxJNZwbaqA5WSbL9NWOitkOkLKT8LAxnq IlZjZ+O2nBosyZruDYCfxjVr5RhSJd/fH6m2hTSj6RGX9SpIWqCyIiNy9LHhUZmpqUcc olKh8sDy3JjMZnDz+UStwwsrsoBnZLOCH6g1cP/xfhFWAWxWIg4utlbUDIh89AUJdAW+ oP+SngrJCwpVAj0HCKi3wQVeJ08an40M/YRO2gtPIWJYz8Ku0EgnhiDHvEKO784GWMNB mz2w== X-Gm-Message-State: AFuF++lkpL6fOdKFH/5ojpylTk/T1WPqR38pLSHuUnDYXksDVlRQBwLU 3qv6Kj2x0Bc1lv8nX5EWgfbIrzmcLdXWRYg2uyz9cpBPLOkUWruWSvs5sjhOEg== X-Gm-Gg: AR+sD10GRHaUqpDpgL3TxjBm8Xj2+UjEcZyeeLDaK/g6HvXIIOv4IDGA53SW7Z7gtvA GNEGK9oJ2I5gNmXvnga44q6UaLZ3pYnkqr49lTDqpQjw1Y+AvUNw41TipvsWB37wFNws6b8h5Us VXiV1wRMX72HRzoCs0p+DqQB9akRmJVWn1u2DznxGqLJDzd5uOSJFi8Jh7s+74R+WxpHzeK44qq hmhtdusX+mG+c581Yn5395efvbyh3ILZ7GjAsPzaxbfLd+Ep4bH5WzXndpwILzT4FhfDu+cZ1fJ 6n3a9/h+bPjMUwPntEJGwnaY/oXCdP7Xkydn0QwARNC1URHv3AVHpp3mj3T8eTEdFE9YAcl0m4N jXCu4FZsqARG6ROqkCSDCdwY+qneAgihnoSEmiKcDVXJFIGttB+xP0ZSeToZ5qcVoHa+ia+MGoV pCqR81ATZUMg5wx3pgeYePbMm2GN2tsOD88sIcqWJVSB0eQwjc+5zZfbFuVb0ky1kQFJgQy6r8S 4AqIsNwzD9WLD15QFBt7FtCdGbbsPNBxuF9oAVs9vw= X-Received: by 2002:a05:600c:5252:b0:49b:9113:e04a with SMTP id 5b1f17b1804b1-49b9113e19amr17929015e9.1.1787844144750; Thu, 27 Aug 2026 08:22:24 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 29/39] xen/riscv: introduce aplic_reconfigure_target() Date: Thu, 27 Aug 2026 17:21:13 +0200 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-4011c0/1787844145-516C6CFC-3D451505/10/73395122804 X-purgate-type: spam X-purgate-size: 2895 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844184483158500 Content-Type: text/plain; charset="utf-8" When a vCPU is migrated to a different pCPU, its IMSIC guest interrupt file changes. Any APLIC interrupt previously configured to deliver an MSI to the old interrupt file must be retargeted to the new one. Implement aplic_reconfigure_target() to scan all interrupts allocated to the domain and update their APLIC TARGET registers accordingly. Signed-off-by: Oleksii Kurochko --- Changes in v2: - New patch. --- --- xen/arch/riscv/aplic.c | 42 ++++++++++++++++++++++++++++++ xen/arch/riscv/include/asm/aplic.h | 4 +++ 2 files changed, 46 insertions(+) diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c index b4c419755ac3..0af13f28e467 100644 --- a/xen/arch/riscv/aplic.c +++ b/xen/arch/riscv/aplic.c @@ -138,6 +138,48 @@ uint32_t aplic_msi_target_gen(const struct vcpu *targe= t_vcpu, return base_val; } =20 +void aplic_reconfigure_target(const struct vcpu *v, + unsigned int old_guest_file_id, + unsigned int old_cpu) +{ + const struct vintc *vintc =3D v->domain->arch.vintc; + const unsigned long *auth_irq_bmp =3D vintc->used_irqs; + unsigned long old_hart_field =3D aplic_hart_field(old_cpu); + unsigned long flags; + unsigned int irqn; + + /* Support only MSI mode at the moment */ + BUG_ON(!aplic_msi_mode()); + + spin_lock_irqsave(&aplic.lock, flags); + + bitmap_for_each ( irqn, auth_irq_bmp, vintc->nr_virqs ) + { + volatile uint32_t __iomem *ptarget; + uint32_t target_val; + unsigned int guest_index, hart_index; + + if ( !irqn ) + continue; + + ptarget =3D &aplic.regs->target[irqn - 1]; + target_val =3D readl(ptarget); + + guest_index =3D MASK_EXTR(target_val, APLIC_TARGET_GUEST_IDX); + hart_index =3D MASK_EXTR(target_val, APLIC_TARGET_HART_IDX); + + if ( (guest_index !=3D old_guest_file_id) || + (hart_index !=3D old_hart_field) ) + continue; + + target_val =3D aplic_msi_target_gen(v, target_val); + + writel(target_val, ptarget); + } + + spin_unlock_irqrestore(&aplic.lock, flags); +} + uint32_t aplic_hw_read_reg(unsigned int offset) { unsigned long flags; diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/as= m/aplic.h index d629e1c83887..8564f5954b6b 100644 --- a/xen/arch/riscv/include/asm/aplic.h +++ b/xen/arch/riscv/include/asm/aplic.h @@ -174,4 +174,8 @@ struct aplic_regs { uint32_t aplic_hw_read_reg(unsigned int offset); void aplic_hw_write_reg(unsigned int offset, uint32_t value); =20 +void aplic_reconfigure_target(const struct vcpu *v, + unsigned int old_guest_file_id, + unsigned int old_cpu); + #endif /* ASM_RISCV_APLIC_H */ --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844171; cv=none; d=zohomail.com; s=zohoarc; b=nxo/G7/Zdf8cFHwTVo01HjcR8LMGx+NaanVhXnN7rluMmZAnSVnK7TxR6KRYBIRQgmtzC3wTpZj6ssM1QpV7cdbqa0bgykro84vyY0/zeyOGB74bnmVsQ1Nw+psj6a7AY6z51ko+JFmE+8nmQ1rFtq/2sI8r9gaYyro00RS429k= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844171; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=pjeR4g3eAicMAUdV6Amf67usumS/lrCxP1G6haAdnIE=; b=QdHiViQcxak6rKNwfjG6clDdi1u6WmkW1zPEhPG3jo1WXbNLMGyil52RDec9tnR1Zm1Ct4khXzjrtbPfkbeGGc2ieAavE6Rl2XUgy/PFFAK1iDhNCb0pWhm3NveFe8ajtdol9Sdeo5FLHI24/D6Re8dERXXraQPoJpEeJOVEZbY= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844171935577.1000776809863; Thu, 27 Aug 2026 08:22:51 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1401000.1636789 (Exim 4.92) (envelope-from ) id 1wzbw4-0007RM-Qi; Thu, 27 Aug 2026 15:22:36 +0000 Received: by outflank-mailman (output) from mailman id 1401000.1636789; Thu, 27 Aug 2026 15:22:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbw3-0007NH-JT; Thu, 27 Aug 2026 15:22:35 +0000 Received: by outflank-mailman (input) for mailman id 1401000; Thu, 27 Aug 2026 15:22:28 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvv-0005pb-G6 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:27 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvu-00C7F4-Sj for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:26 +0200 Received: from [10.42.69.5] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a90562c-e002-0a2a0a5209dd-0a2a4505e5e4-12 for ; Thu, 27 Aug 2026 17:22:26 +0200 Received: from [209.85.128.53] (helo=mail-wm1-f53.google.com) by tlsNG-c201ff.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a905632-4cb1-0a2a45050019-d1558035e460-3 for ; Thu, 27 Aug 2026 17:22:26 +0200 Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4953de5be0aso17665605e9.0 for ; Thu, 27 Aug 2026 08:22:26 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:25 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844146; x=1788448946; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=pjeR4g3eAicMAUdV6Amf67usumS/lrCxP1G6haAdnIE=; b=axi1JGDG3EF5PNUSuc5s9fUUiLXudV9YdTEwI+9c8r1eiB8drQUem+nKttoc57JTTC UXG7m1lNRaZpDf56X+eBrqnmFGcYMemfp646NEOuttSyPoLYGeT+wOTJbMiyAgAaZVZB /Y+ruXQH8VhBf0mFNB53Rx+Z4pYInSwjGJYa5I6xAgrnQE4M2N8g3WcTweZLcfL6ZsuJ FNJIUE/PmRptDdwDK1puebZxbOxvQMc4I6gde+rw2CSCbeoyrSRWV0QPsMAEbYwvFuZd ETrLnn7+NQ/KDXN9LEE117GLG1jf0ATl1GiP9HixQ3RjY5ym7RjDorn5/FKKqLgNn+OK le8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844146; x=1788448946; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=pjeR4g3eAicMAUdV6Amf67usumS/lrCxP1G6haAdnIE=; b=UR3qM/1iSMKDuKumLzzKlpCt/Uqv+B3BVNsMZ5bOV3/jaYp8aXVZMQb6o4QR+ZhFR5 RvOD8yUmJng67Sfn2fECPClhTSiS/YcKlO52ZOxw5ACHaSIG9EP95ZX82HiAPwLak7Ih ykMgwmw5bmXOWShoKqsBT9alSqb/3dfg3MdtiMdKKLRF797QGNit/uTTvW6kgJDMci5e QNK7+JgN9fen3Yx2wLaC5oo5Pyl0Esug4pDt1itoWCRJP1CSFClZJQqda9UVOlXAAhd2 kX19KTA2TJjagcrSGOEUjmqg+u8EJt9RAQ8zY945h0ltPoy/v3gJ3Y3IQBiqzTL0EftS 8Vuw== X-Gm-Message-State: AFuF++npbIIXdBjKxwGQGG2PaOqmyfk9Ydx9peqqUQIeT24wFlCVh+el qUhS47yL2TzWfHVIJe/abffMxk+iz55CYxVmrzczrxWkCQoyVqTWNTEdaT8/fg== X-Gm-Gg: AR+sD10w/6SNFDhUJZMvzXBPZa9DI6ikKZIkH3xWO34SMUAmIo4NwSAgWYOWsZ3xLXE RmvpuMlHPMo1Ckl/B8Veceqnv448wE5xmTHVXu/jxH9X8/l9Y+JLVhQzrIJnck6qpLMfA6RahPD rjFScpkbgAqWZDP3K8cXlrJdypStvmdz6G08SCdJ4zyJugFfbOKz80AzvFq2Z886Mg9Wn3A14Z4 mVMyzjDh4T0pdbyzxdFajjAIUTFoH5HBSvXimxuOnROXnh5BgsZ2f/EnYttVZao5wxY22wEP56t 9AglgNWTNTyLpQ2VR5L+yagvIuR5ds69wHutWYpHjyVx+8hpUmd302tBk/C8xi56I7OGNjVNYpu QcIM8F1wOmLtPnwHSEcslKwmVy3z51t+OewAJb03ZNhV0XB6baBtj4XY7AK45tc2iTKHTS+3jDM oc6Z5XZr7JlDSwPWswHRWegSiCy3A88LcwzwC0OoV9OTa4MC9haUcI4cRAPXPf3q1PJjv9Xm8wc BADIw1i7q5zXvVJ/FOPBLQrkVku7y2u X-Received: by 2002:a05:600c:34c3:b0:499:afe2:e4d0 with SMTP id 5b1f17b1804b1-499dc70d263mr195585985e9.8.1787844146120; Thu, 27 Aug 2026 08:22:26 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 30/39] xen/riscv: prepare new IMSIC VS-file Date: Thu, 27 Aug 2026 17:21:14 +0200 Message-ID: <440bc07dfb72d09da72b49ded6f78dc1f54a3ad5.1787838835.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-c201ff/1787844146-F52A32A1-A3BF8177/10/73395122804 X-purgate-type: spam X-purgate-size: 9361 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844172463158500 Content-Type: text/plain; charset="utf-8" Implement first steps of migration a vCPU to a different guest interrupt fi= le procedure: - At the old interrupt file, save to memory the values of registers eidelivery and eithreshold, and set eidelivery =3D 0. - At the new interrupt file, set eidelivery =3D 0, and zero all implemented interrupt-pending bits (the eip array). The following steps will be introduced in follow-up patches. Add a BUG_ON("unimplemented") placeholder in imsic_migrate_vcpu() to guard against silent incorrect behaviour or unexpected panics in guest VMs until the function is fully implemented. vgein_assign() will be introduced later in a separate patch, for not it is only stub. Signed-off-by: Oleksii Kurochko --- Changes in v2: - New patch. --- --- xen/arch/riscv/aia.c | 9 ++ xen/arch/riscv/imsic.c | 159 +++++++++++++++++++++++++++++++ xen/arch/riscv/include/asm/aia.h | 4 + xen/include/xen/config.h | 1 + 4 files changed, 173 insertions(+) diff --git a/xen/arch/riscv/aia.c b/xen/arch/riscv/aia.c index e31c9c2d24b6..75c82bcfa1b3 100644 --- a/xen/arch/riscv/aia.c +++ b/xen/arch/riscv/aia.c @@ -1,8 +1,10 @@ /* SPDX-License-Identifier: GPL-2.0-only */ =20 +#include #include #include #include +#include #include =20 #include @@ -21,3 +23,10 @@ void __init aia_init(void) =20 _aia_usable =3D true; } + +unsigned int vgein_assign(struct vcpu *v) +{ + BUG_ON("unimplemented\n"); + + return 0; +} diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c index ad7fbe708bfd..516f0105352a 100644 --- a/xen/arch/riscv/imsic.c +++ b/xen/arch/riscv/imsic.c @@ -26,6 +26,7 @@ #include #include =20 +#include #include =20 #define IMSIC_HART_SIZE(guest_bits) (BIT(guest_bits, U) * IMSIC_MMIO_PAGE_= SZ) @@ -77,6 +78,64 @@ do { \ csr_clear(CSR_SIREG, v); \ } while (0) =20 +#define imsic_vs_csr_write(c, v) \ +do { \ + csr_write(CSR_VSISELECT, (c)); \ + csr_write(CSR_VSIREG, (v)); \ +} while ( 0 ) + +/* + * Generic switchcase expansion pyramid. + * F is the per-operation leaf macro, ireg is the base register index. + * Optional extra args (e.g. an operation and/or a value) are forwarded to= F + * via __VA_ARGS__. + * + * imsic_switchcase_break(ireg, op, v) - emit "case ireg: op(ireg,v); brea= k;" + * imsic_switchcase_ret(ireg, op, ...) - emit "case ireg: return op(ireg[,= v]);" + * The variadic tail is optional so the same leaf works for both read (n= o v) + * and swap (with v). + */ +#define imsic_switchcase_break(ireg, op, v) \ + case ireg: \ + op(ireg, v); \ + break; + +#define imsic_switchcase_ret(ireg, op, ...) \ + case ireg: \ + return op(ireg, ##__VA_ARGS__); + +#define imsic_switchcase_2(F, ireg, ...) \ + F(ireg + 0, ##__VA_ARGS__) \ + F(ireg + 1, ##__VA_ARGS__) +#define imsic_switchcase_4(F, ireg, ...) \ + imsic_switchcase_2(F, ireg + 0, ##__VA_ARGS__) \ + imsic_switchcase_2(F, ireg + 2, ##__VA_ARGS__) +#define imsic_switchcase_8(F, ireg, ...) \ + imsic_switchcase_4(F, ireg + 0, ##__VA_ARGS__) \ + imsic_switchcase_4(F, ireg + 4, ##__VA_ARGS__) +#define imsic_switchcase_16(F, ireg, ...) \ + imsic_switchcase_8(F, ireg + 0, ##__VA_ARGS__) \ + imsic_switchcase_8(F, ireg + 8, ##__VA_ARGS__) +#define imsic_switchcase_32(F, ireg, ...) \ + imsic_switchcase_16(F, ireg + 0, ##__VA_ARGS__) \ + imsic_switchcase_16(F, ireg + 16, ##__VA_ARGS__) +#define imsic_switchcase_64(F, ireg, ...) \ + imsic_switchcase_32(F, ireg + 0, ##__VA_ARGS__) \ + imsic_switchcase_32(F, ireg + 32, ##__VA_ARGS__) + +static void imsic_eix_write(unsigned int ireg, unsigned long val) +{ + switch ( ireg ) + { + imsic_switchcase_64(imsic_switchcase_break, IMSIC_EIP0, + imsic_vs_csr_write, val) + imsic_switchcase_64(imsic_switchcase_break, IMSIC_EIE0, + imsic_vs_csr_write, val) + default: + ASSERT_UNREACHABLE(); + } +} + unsigned int vcpu_guest_file_id(const struct vcpu *v) { return ACCESS_ONCE(v->arch.vimsic_state->guest_file_id); @@ -389,6 +448,76 @@ int cf_check vcpu_imsic_init(struct vcpu *v) return 0; } =20 +/* + * Arguments of the imsic_vsfile_local_*() helpers, which are executed by = the + * pCPU owning the interrupt file, thereby through imsic_call_on_cpu(). + */ +struct imsic_vsfile_data { + unsigned int hgei; + unsigned int nr_eix; + struct imsic_mrif *mrif; +}; + +/* + * Execute func() on the pCPU which owns the IMSIC interrupt file func() is + * going to work with. + * + * An IMSIC VS-file is reachable only through hstatus.VGEIN of the hart the + * file belongs to, and a guest interrupt file index is meaningless on any + * other hart, so such work always has to be done by that very hart. + * + * The local case runs with IRQs disabled to provide func() with the same + * environment it is given when it is called from the function call IPI + * handler. + */ +static void imsic_call_on_cpu(unsigned int cpu, void (*func)(void *), + void *data) +{ + if ( cpu =3D=3D smp_processor_id() ) + { + unsigned long flags; + + local_irq_save(flags); + func(data); + local_irq_restore(flags); + } + else + on_selected_cpus(cpumask_of(cpu), func, data, 1); +} + +static void cf_check imsic_vsfile_local_clear(void *data) +{ + unsigned int i; + const struct imsic_vsfile_data *idata =3D data; + unsigned long new_hstatus, old_hstatus, old_vsiselect; + + /* We can only zero-out if we have a IMSIC VS-file */ + if ( !idata->hgei ) + return; + + old_vsiselect =3D csr_read(CSR_VSISELECT); + old_hstatus =3D csr_read(CSR_HSTATUS); + new_hstatus =3D old_hstatus & ~HSTATUS_VGEIN; + new_hstatus |=3D MASK_INSR(idata->hgei, HSTATUS_VGEIN); + csr_write(CSR_HSTATUS, new_hstatus); + + imsic_vs_csr_write(IMSIC_EIDELIVERY, 0); + imsic_vs_csr_write(IMSIC_EITHRESHOLD, 0); + + for ( i =3D 0; i < idata->nr_eix; i++ ) + { + imsic_eix_write(IMSIC_EIP0 + i * 2, 0); + imsic_eix_write(IMSIC_EIE0 + i * 2, 0); +#ifdef CONFIG_RISCV_32 + imsic_eix_write(IMSIC_EIP0 + i * 2 + 1, 0); + imsic_eix_write(IMSIC_EIE0 + i * 2 + 1, 0); +#endif + } + + csr_write(CSR_HSTATUS, old_hstatus); + csr_write(CSR_VSISELECT, old_vsiselect); +} + void cf_check vcpu_imsic_deinit(struct vcpu *v) { XVFREE(v->arch.vimsic_state); @@ -689,6 +818,14 @@ int __init vimsic_make_domu_dt_node(struct kernel_info= *kinfo, =20 void imsic_migrate_vcpu(struct vcpu *v) { + unsigned int new_vsfile_hgei; + unsigned int new_vsfile_cpu; + unsigned int nr_hw_eix =3D DIV_ROUND_UP(imsic_cfg.nr_ids + 1, + BITS_PER_TYPE(uint64_t)); + struct imsic_vsfile_data vsfile_data =3D { + .nr_eix =3D nr_hw_eix, + }; + /* * The scheduler can mark a freshly created vCPU's unit as migrated and * invoke this before the vCPU has ever run (see the migrated branch in @@ -699,5 +836,27 @@ void imsic_migrate_vcpu(struct vcpu *v) if ( v->arch.last_cpu =3D=3D NR_CPUS ) return; =20 + /* + * At this point, all interrupt producers are still using the old IMSIC + * VS-file. + */ + + /* + * Latch the pCPU the new interrupt file is taken from: vgein_assign() + * allocates it from v->processor's pool of guest interrupt files, and + * only that hart can access the file afterwards. + */ + new_vsfile_cpu =3D v->processor; + + new_vsfile_hgei =3D vgein_assign(v); + + /* We don't support SW interrupt files at the moment. */ + BUG_ON(!new_vsfile_hgei); + + vsfile_data.hgei =3D new_vsfile_hgei; + + /* Zero-out new IMSIC VS-file */ + imsic_call_on_cpu(new_vsfile_cpu, imsic_vsfile_local_clear, &vsfile_da= ta); + BUG_ON("unimplemented"); } diff --git a/xen/arch/riscv/include/asm/aia.h b/xen/arch/riscv/include/asm/= aia.h index aaa4bf91fc75..53a1efb042f8 100644 --- a/xen/arch/riscv/include/asm/aia.h +++ b/xen/arch/riscv/include/asm/aia.h @@ -3,8 +3,12 @@ #ifndef RISCV_AIA_H #define RISCV_AIA_H =20 +struct vcpu; + bool aia_usable(void); =20 void aia_init(void); =20 +unsigned int vgein_assign(struct vcpu *v); + #endif /* RISCV_AIA_H */ diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h index dddc8e1920fe..0e29976e8203 100644 --- a/xen/include/xen/config.h +++ b/xen/include/xen/config.h @@ -100,6 +100,7 @@ #define BITS_PER_INT (BITS_PER_BYTE * __SIZEOF_INT__) #define BITS_PER_LONG (BITS_PER_BYTE * BYTES_PER_LONG) #define BITS_PER_LLONG (BITS_PER_BYTE * __SIZEOF_LONG_LONG__) +#define BITS_PER_TYPE(type) (sizeof(type) * BITS_PER_BYTE) =20 /* It is assumed that sizeof(void *) =3D=3D __alignof(void *) */ #define POINTER_ALIGN __SIZEOF_POINTER__ --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844189; cv=none; d=zohomail.com; s=zohoarc; b=YMil4/JQKPEvKfuf40A7qumScQhYOxPbQLpKKU0xm4gv570qPw9ZX3HnapS1th5ddO37OYyZLihRlGNgST+wHAaV3pVXS5tlBrN1H6pCGUBvmlVFuxb6Je5TjguJ27Ahf3uVE8qt++nVPq3MS17rUKAharzzxPv+OKoOueFn5Vs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844189; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=MsgUegOsMRroKwEVJzn4qlUJHeFHlyzxMsZorMiGJUg=; b=AqbIwzMmOItngAZ511EOuCvHBZDnR2fO2rqv8wV+GwF8MwSSw7TEEvMR4NEVrHE2q/0xGIgW7oPY71CfIefz3b6aK2f3xHAKfVEEEUYL5pRpMewNSiQRo+FwSkpTs6zlZ/c1F4j7S9iLZxvxueOIAEoNoQCGk3QA5YWDymhz/m8= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844189235267.36949373941957; Thu, 27 Aug 2026 08:23:09 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1401003.1636798 (Exim 4.92) (envelope-from ) id 1wzbw8-00080f-46; Thu, 27 Aug 2026 15:22:40 +0000 Received: by outflank-mailman (output) from mailman id 1401003.1636798; Thu, 27 Aug 2026 15:22:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbw6-0007sH-E8; Thu, 27 Aug 2026 15:22:38 +0000 Received: by outflank-mailman (input) for mailman id 1401003; Thu, 27 Aug 2026 15:22:29 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvw-00061F-Kk for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:28 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvw-009l5h-0d for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:28 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a905633-8faa-0a2a0a5109dd-0a2a450293fc-2 for ; Thu, 27 Aug 2026 17:22:27 +0200 Received: from [209.85.221.47] (helo=mail-wr1-f47.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a905633-6ca4-0a2a45020019-d155dd2fe4a8-3 for ; Thu, 27 Aug 2026 17:22:27 +0200 Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-482ea739de2so825835f8f.0 for ; Thu, 27 Aug 2026 08:22:27 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:27 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844147; x=1788448947; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=MsgUegOsMRroKwEVJzn4qlUJHeFHlyzxMsZorMiGJUg=; b=jPKv+VZHqmrXQ+wpOBzC1pIZ/Pt26uOUJUyXJ1vl+t0XreALz24dW2NBUNpzodbYk7 OpncygdQOzqwR4i4MtkPuk0DYK7AKQukvR86sM+vl0eDsC1t+ciYL/WjfaxbyTs1zw09 Y1+DKsaUel00H6im69YGz/dtOOKK+z4coUaDApDujtcuHXZOfuQ4mhbXjhHyXEXnjopq 06+haSQ+U0uXN3NgmUuLUjQ8QCmQAez4SR7XeyfQs4vO3/cj+3HPzvk3XpSCg2xsPI8u fp3EFTAKU7tRZc7y/UpcgGnnezyW60CnNtHTUTCKRZkYCFPOOFYfANCOAe3pSulw+mlB 8MZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844147; x=1788448947; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=MsgUegOsMRroKwEVJzn4qlUJHeFHlyzxMsZorMiGJUg=; b=WT6Wphmgp62vSNds/iwho8MzHlVROaGRixlnXXYzj7MsWemZZN9Vuu9ygyYgKt5XuU zkL7pRvuT7tq+qR4N53WPp0PwyxzhSYk6ppCq0V1nC6byPs+ZMK+p7AQca/AKigXlGsa oRD3XbAUTEC9LSqMNZvuFQHxSavPj5vyEpNwlddK9ozYPKbVxHsqMVlX8DCPXFbsfQf8 ICXzo82va0VEA41Q79+XFwKXr9mn14AKA6Z/9W6KtmVU9CTTZVFP2+E4UPbS9ot2kKIL 1J+sa7zd3z3oPbz0eBrht7xXjMe59DXmNiwBE6lKeu0ugcIUq/Kwp2K9zZbQ3XQ/DhoU mLLw== X-Gm-Message-State: AFuF++m97P6sBAtGqzk1mXjD8IeMR1vcnk1T2gsFmLK94m1ffT/Z75mB 3OxpF2UFASheffBpngjqA1cRxdkT3UiZDYPghWK3Flg2PZkxVbWmh2RiqnZHmQ== X-Gm-Gg: AR+sD13RzE6bni9GV0QMN5wZfgRqVT7UjaSFo0UUwh0btxunTVCEV11EDfBi7yNafed PMWT5WE7pXV9INWyJXl2hwUF9h6FLk0N6OgtyjnWVzi6Jjsm1wNIBURDrT6DthkxYYx1Tna++L4 VWRMnul7YT2wR6GDlTXTQWTLQq7fCS1LGfHOtJJ+40vtvBIooN3C5/gau9nNQJY39UV3Qk86qIB X7o+1WyfPwKtlwSimQRCrwpC1ncQupiI1ZDeaT4zmiAn79GjzAHt6tDP5cFjspTyl5wn7U6sHjn IQNvsEr1bwgvs4rpxyA+QvvrqWAYahhdgUhilcYORdv765K6BoQnbFLpFC1qURDU2vzDQQhFlcp 7wY/O845GCrf2YiuHor08mN8PQGxZvgNBxrxKNdy1kYmdFDN2fKRTan/1YPSBrQjLJPyc/yU/13 u8Tw0PVBu9vPXBr8Sp5JDwqiRiIv75O+4JbXFxXgDzX6faidFzea1puKjYUeyy74M2gM5uljVJr LPTVS8R5cguQCdrLyfRGiwwEXO58BqZPDGpR0nK+ec= X-Received: by 2002:a05:600c:8b75:b0:499:db6d:bc97 with SMTP id 5b1f17b1804b1-499dc6a4a85mr194824605e9.0.1787844147329; Thu, 27 Aug 2026 08:22:27 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 31/39] xen/riscv: implement APLIC-hart sync barrier for vCPU migration Date: Thu, 27 Aug 2026 17:21:15 +0200 Message-ID: <3d953b6e7f221f4cf4143454076466fab38b6236.1787838835.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-720697/1787844147-F3CBA2AC-1E57114B/10/73395122804 X-purgate-type: spam X-purgate-size: 4460 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844190526158501 Content-Type: text/plain; charset="utf-8" During migration of a virtual hart to a different guest interrupt file, straggler MSIs from the APLIC could arrive at the old interrupt file after the switch. genmsi is used despite not supporting guest interrupt files because the AIA spec guarantees that all MSIs previously sent from the APLIC to the same hart are visible at the hart's IMSIC before the extempore MSI from genmsi becomes visible. Signed-off-by: Oleksii Kurochko --- Changes in v2: - New patch. --- --- xen/arch/riscv/aplic.c | 26 ++++++++++++++++++++++++++ xen/arch/riscv/imsic.c | 12 ++++++++++++ xen/arch/riscv/include/asm/aplic.h | 3 +++ xen/arch/riscv/include/asm/imsic.h | 8 ++++++++ 4 files changed, 49 insertions(+) diff --git a/xen/arch/riscv/aplic.c b/xen/arch/riscv/aplic.c index 0af13f28e467..cb11d6aeaaa9 100644 --- a/xen/arch/riscv/aplic.c +++ b/xen/arch/riscv/aplic.c @@ -27,7 +27,9 @@ #include #include #include +#include #include +#include =20 static struct aplic_priv aplic =3D { .lock =3D SPIN_LOCK_UNLOCKED, @@ -205,6 +207,30 @@ void aplic_hw_write_reg(unsigned int offset, uint32_t = value) spin_unlock_irqrestore(&aplic.lock, flags); } =20 +/* + * As needed, synchronize with all IOMMUs and APLICs to ensure that no + * straggler MSIs will arrive at the old interrupt file after this step. + */ +void aplic_genmsi_barrier(void) +{ + const struct imsic_config *imsic =3D imsic_get_config(); + unsigned int cpu =3D smp_processor_id(); + unsigned long flags; + uint32_t val; + + val =3D MASK_INSR(aplic_hart_field(cpu), APLIC_TARGET_HART_IDX) | + (imsic->sync_id & APLIC_TARGET_EIID); + + spin_lock_irqsave(&aplic.lock, flags); + + writel(val, &aplic.regs->genmsi); + + while ( readl(&aplic.regs->genmsi) & APLIC_GENMSI_BUSY ) + cpu_relax(); + + spin_unlock_irqrestore(&aplic.lock, flags); +} + static void __init aplic_init_hw_interrupts(void) { unsigned int i; diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c index 516f0105352a..5de45949610d 100644 --- a/xen/arch/riscv/imsic.c +++ b/xen/arch/riscv/imsic.c @@ -195,6 +195,15 @@ void imsic_irq_enable(unsigned int irq) */ ASSERT(!local_irq_is_enabled()); =20 + if ( irq =3D=3D imsic_cfg.sync_id ) + { + printk(XENLOG_WARNING + "irq%u is reserved for APLIC sync so shouldn't be set by %s= \n", + irq, __func__); + + return; + } + spin_lock(&imsic_cfg.lock); /* * There is no irq - 1 here (look at aplic_set_irq_type()) because: @@ -377,6 +386,9 @@ static int __init imsic_parse_node(const struct dt_devi= ce_node *node, return -ENOENT; } =20 + /* Reserve last identity for APLIC-to-hart synchronization */ + imsic_cfg.sync_id =3D imsic_cfg.nr_ids; + /* Compute base address */ *nr_mmios =3D 0; rc =3D dt_device_get_address(node, *nr_mmios, &base_addr, NULL); diff --git a/xen/arch/riscv/include/asm/aplic.h b/xen/arch/riscv/include/as= m/aplic.h index 8564f5954b6b..e4f4dfd241cc 100644 --- a/xen/arch/riscv/include/asm/aplic.h +++ b/xen/arch/riscv/include/asm/aplic.h @@ -88,6 +88,7 @@ #define APLIC_SETIPNUM_LE 0x2000 =20 #define APLIC_GENMSI 0x3000 +#define APLIC_GENMSI_BUSY BIT(12, U) =20 #define APLIC_TARGET_BASE 0x3004 #define APLIC_TARGET_LAST 0x3ffc @@ -178,4 +179,6 @@ void aplic_reconfigure_target(const struct vcpu *v, unsigned int old_guest_file_id, unsigned int old_cpu); =20 +void aplic_genmsi_barrier(void); + #endif /* ASM_RISCV_APLIC_H */ diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/as= m/imsic.h index 57d8c729ac0d..6ea2e4b8ca12 100644 --- a/xen/arch/riscv/include/asm/imsic.h +++ b/xen/arch/riscv/include/asm/imsic.h @@ -68,6 +68,14 @@ struct imsic_config { /* Number off interrupt identities */ unsigned int nr_ids; =20 + /* + * Interrupt identity reserved exclusively for APLIC-to-hart + * synchronization. + * + * Must not be allocated to any interrupt source. + */ + unsigned int sync_id; + /* MSI */ const struct imsic_msi *msi; =20 --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844182; cv=none; d=zohomail.com; s=zohoarc; b=WdEboubzJejubmAIYsEANDqo2aASb2HAe+7aGa+Jww7vShjClvud4IjoiFHO/PHy0gsR8TYI//zbld8D8PTn1+5F6YzI2S25QnoQYbhrPx3DJOoa93DLz2Pmc+ZBBJTdlCXXxdnxv451UMOA3T4Rnz1oGpysSYm3be9qyP6+Rhs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844182; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=C2iZ2nZklExeYYf8IYKOjHglR9wLR44Pru73TEFSVXg=; b=GFmAk89sDgmGV+fw5S57SK07yVcFaFn5TT8EYJuijtIiBwrmQ4EryoCIvT5l0Asf9OyKBbNekMEwxiJWUxZgi1lVjNnZrm90YPyDGpnlsvphAUvbAwRwA1T/zfGZCcxgEauT88LzG7eKHrghW0YxHsvZ6kvZanejhCMRobLA218= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844182443949.416285565253; Thu, 27 Aug 2026 08:23:02 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1401007.1636803 (Exim 4.92) (envelope-from ) id 1wzbw8-0008CI-BZ; Thu, 27 Aug 2026 15:22:40 +0000 Received: by outflank-mailman (output) from mailman id 1401007.1636803; Thu, 27 Aug 2026 15:22:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbw7-000871-L8; Thu, 27 Aug 2026 15:22:39 +0000 Received: by outflank-mailman (input) for mailman id 1401007; Thu, 27 Aug 2026 15:22:31 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvy-0006J9-6x for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:30 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvx-003O3L-Fa for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:29 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a905626-e002-0a2a0a5209dd-0a2a4501aa5e-20 for ; Thu, 27 Aug 2026 17:22:29 +0200 Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a905635-5984-0a2a45010019-d155802fd877-3 for ; Thu, 27 Aug 2026 17:22:29 +0200 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-49b0d78a801so11444405e9.2 for ; Thu, 27 Aug 2026 08:22:29 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:28 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844149; x=1788448949; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=C2iZ2nZklExeYYf8IYKOjHglR9wLR44Pru73TEFSVXg=; b=cGh7ElNUuJ48dZeu0lrP3my/bRF92JulA0y/hp9Ny/x+eugzHE1IjtCaOH3NL/ZbI9 gTnUotRAYc4ByegxBH+Ed1qGXCc8pdh2HUNcDCe6088T4WUEPctjqQYMqDPmulI10UVQ K9o4XEM6mueR2gKVwmrg+S0yAC86M0hiZQH7xyxphRAIRq8fS81J5RckaRErtr/SjLcM kl4ZcWDKCq10/lG5112WUvoxlHcF2dPZmv/m3F9x7EDjf7akFNokHZ1N1zE6/8aC2I4Z ibwoATCWox2Z1ADXRVCAE2ujS1pNiq3QY2rka1stwFd/m+uXKyDqNvQmrrgJDlDUZBWw XA+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844149; x=1788448949; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=C2iZ2nZklExeYYf8IYKOjHglR9wLR44Pru73TEFSVXg=; b=dWP8bvbdlcTPIg83EEqigmlD/OrBNr7iar3q1rUkSXiU9rpdbGsnJD64kzlJTk0DAm icCqa5v+75QmhKa89od/TLHFl7+YRsZeM0R0z30+HGL9FXuj8rFsJeXLkFF5F9uO6Qb5 cJ4EzSjWfnYSPbtWo4C7mWxObV6ORahZzWNp5nPYCiP5bQ0vdR1vnLaREzMu5u1kXBRd PC1zBiBtGhAUfzX80AdQIsYafgCo6iV4asIH87t00g8m3GxUzlfnXdE2zgLuPSaGZgvc kvMhtPeJ5BODFAfvBpjf2PdOAfzQxqAD+5ORCSbIxYBOgl28Y9LBh6Vbfwn4LiIZKUR6 eeZw== X-Gm-Message-State: AFuF++mu+iY4bgMLRyMm2Ac/n2thMnxQB1zyYtVTd13GvOT26dd/4hmd uJUUbNUsKiV+5w/6/XsF6vlskN9YZbD7+xq6TDB9abK4Ib9OgteyzRT+0OlcFg== X-Gm-Gg: AR+sD12OPMj5p2Et7/ytT/g17gRCPPXyqonoFP8ZExKkrDmtvp8vAZc4HCKx1x1caLB 1FIljpVhIoWHF7+JZcbyzXTEpDZlvNvXbeGBuRB/Zvsl2uCecmlhKQbmyx3DaMSboZ+wA75k0rp CILS2/ZWQHC2SbfvPxlMMQmtOYPEaD1ipf+cZc9QeXfSG2bsTtXXHIRPTxX703WkdH+k5mDoyQG trTXPpuryRL75HwxZX5/mR52vaVEbFQhzF/I/nDmyFKoy/mpsLFLgAG1ClSRokjI95z3Dvg3X58 j9Xn4IOpMYFrgOCqyd1bMnI1LszmjyD1ShomGr4epGbpNHY4ZhEvA2+Z8sdRlMLcCkLULx8c6r1 0JNA/H+Aiq61eNkgxF8uyEn1x0SpsMZ9iz2GnzlEIMLVUk6Lz2JO5wdQB3xBngoJwH2Jn0UgISr EkIjwLOpy0c7Q74goNyDUN1jOzF/4KlpbPL5S0Co/gDxN4oYPv4Wl3KgwC6Xyp1wM3uL707xpu1 8euq9+E3yvEPZK3Uo3llnZ0z464RGHA X-Received: by 2002:a05:600c:860b:b0:499:726a:a017 with SMTP id 5b1f17b1804b1-499dc6e0040mr198008185e9.1.1787844148669; Thu, 27 Aug 2026 08:22:28 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 32/39] xen/riscv: remap interrupts to new IMSIC VS-file Date: Thu, 27 Aug 2026 17:21:16 +0200 Message-ID: <948e94b6610586b84626c98da033d301335dc7b0.1787838835.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d62444/1787844149-BD87F757-2926A577/10/73395122804 X-purgate-type: spam X-purgate-size: 8276 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844184560158501 Content-Type: text/plain; charset="utf-8" After new IMSIC VS-file is zeroed-out it is necessary to do G-stage remaping fo new IMSIC VS-file. Also, if any interrupts at an APLIC are forwarded by MSIs to the old interrupt file, reconfigure the APLIC to send them to the new interrupt file. Generally it is needed also to modify the relevant translation tables at all IOMMUs so that MSIs for this virtual interrupt file are now sent to the new physical interrupt file but it is skipped for now there is no IOMMU support for RISC-V. Synchronize with APLIC to ensure that no straggler MSIs will arrive at the old interrupt file by using of aplic_genmsi_barrier(). Technically there is no need for read_lock_irqsave() and read_unlock_irqrestore() around reading of ->guest_file_id, as a write cannot happen in parallel: any update to ->guest_file_id for a vCPU will happen either in imsic_migrate_vcpu() itself or before the vCPU first gains control (in continue_new_vcpu()), so there is no concurrent access to it in imsic_migrate_vcpu(). The lock is added here for potential future cases. Keep BUG_ON("unimplemented") placeholder in imsic_migrate_vcpu() to guard against silent incorrect behaviour or unexpected panics in guest VMs until the function is fully implemented. imsic_map_guest_file() and imsic_update_state() are stubs for now and will be introduced later in a separate patch. Signed-off-by: Oleksii Kurochko --- Changes in v2: - New patch. --- --- xen/arch/riscv/imsic.c | 103 +++++++++++++++++++++++++++++ xen/arch/riscv/include/asm/imsic.h | 3 + 2 files changed, 106 insertions(+) diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c index 5de45949610d..5e9f6995e443 100644 --- a/xen/arch/riscv/imsic.c +++ b/xen/arch/riscv/imsic.c @@ -27,6 +27,7 @@ #include =20 #include +#include #include =20 #define IMSIC_HART_SIZE(guest_bits) (BIT(guest_bits, U) * IMSIC_MMIO_PAGE_= SZ) @@ -60,6 +61,12 @@ static unsigned int __ro_after_init guest_num_msis; #define IMSIC_DISABLE_EITHRESHOLD 1 #define IMSIC_ENABLE_EITHRESHOLD 0 =20 +#define imsic_csr_read(c) \ +({ \ + csr_write(CSR_SISELECT, (c)); \ + csr_read(CSR_SIREG); \ +}) + #define imsic_csr_write(c, v) \ do { \ csr_write(CSR_SISELECT, c); \ @@ -141,6 +148,11 @@ unsigned int vcpu_guest_file_id(const struct vcpu *v) return ACCESS_ONCE(v->arch.vimsic_state->guest_file_id); } =20 +void imsic_update_state(struct vcpu *v, unsigned int guest_file_id) +{ + BUG_ON("unimplemented\n"); +} + void __init imsic_ids_local_delivery(bool enable) { if ( enable ) @@ -242,6 +254,15 @@ void imsic_irq_disable(unsigned int irq) spin_unlock(&imsic_cfg.lock); } =20 +static bool imsic_local_is_pending(unsigned int id) +{ + unsigned long isel =3D + (id / BITS_PER_LONG) * (BITS_PER_LONG / IMSIC_EIPx_BITS) + IMSIC_E= IP0; + unsigned long bit =3D BIT(id % BITS_PER_LONG, UL); + + return !!(imsic_csr_read(isel) & bit); +} + /* Callers aren't intended to changed imsic_cfg so return const. */ const struct imsic_config *imsic_get_config(void) { @@ -436,6 +457,11 @@ void cf_check imsic_ctxt_switch_to(struct vcpu *v) /* Nothing to do */ } =20 +int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id) +{ + return -EOPNOTSUPP; +} + int cf_check vcpu_imsic_init(struct vcpu *v) { struct vimsic_state *imsic_state; @@ -497,6 +523,27 @@ static void imsic_call_on_cpu(unsigned int cpu, void (= *func)(void *), on_selected_cpus(cpumask_of(cpu), func, data, 1); } =20 +/* + * Ensure that all the MSIs the APLIC has already generated for the hart t= his + * runs on have really reached the hart's IMSIC. + * + * The barrier is the one described by the AIA specification in + * "Synchronizing interactions between a hart and the APLIC": ask the APLI= C to + * send an MSI to the hart itself and wait until it shows up as pending in= the + * hart's own interrupt file. As it says nothing about MSIs on their way to + * any other hart, it has to be executed by the pCPU owning the interrupt = file + * the MSIs were being sent to. + */ +static void cf_check imsic_aplic_sync(void *data) +{ + imsic_local_eix_update(imsic_cfg.sync_id, 1, true, false); + + aplic_genmsi_barrier(); + + while ( !imsic_local_is_pending(imsic_cfg.sync_id) ) + cpu_relax(); +} + static void cf_check imsic_vsfile_local_clear(void *data) { unsigned int i; @@ -837,6 +884,10 @@ void imsic_migrate_vcpu(struct vcpu *v) struct imsic_vsfile_data vsfile_data =3D { .nr_eix =3D nr_hw_eix, }; + struct vimsic_state *imsic_state =3D v->arch.vimsic_state; + unsigned long flags; + unsigned int old_vsfile_id; + unsigned int old_vsfile_cpu; =20 /* * The scheduler can mark a freshly created vCPU's unit as migrated and @@ -848,8 +899,22 @@ void imsic_migrate_vcpu(struct vcpu *v) if ( v->arch.last_cpu =3D=3D NR_CPUS ) return; =20 + read_lock_irqsave(&imsic_state->vsfile_lock, flags); + old_vsfile_id =3D imsic_state->guest_file_id; + old_vsfile_cpu =3D imsic_state->vsfile_cpu; + read_unlock_irqrestore(&imsic_state->vsfile_lock, flags); + + /* + * We don't support SW interrupt files at the moment. Bail out before + * anything is touched, as the old file has no owning pCPU in that case + * and there is nothing to retarget the producers away from. + */ + if ( old_vsfile_cpu =3D=3D NR_CPUS ) + panic("IMSIC SW-file isn't supported\n"); + /* * At this point, all interrupt producers are still using the old IMSIC + * VS-file so we first move all interrupt producers to the new IMSIC * VS-file. */ =20 @@ -870,5 +935,43 @@ void imsic_migrate_vcpu(struct vcpu *v) /* Zero-out new IMSIC VS-file */ imsic_call_on_cpu(new_vsfile_cpu, imsic_vsfile_local_clear, &vsfile_da= ta); =20 + /* Update G-stage mapping for the new IMSIC VS-file */ + if ( imsic_map_guest_file(v, new_vsfile_hgei) ) + { + domain_crash(v->domain, "Migration to hw interrupt file failed\n"); + + return; + } + + imsic_update_state(v, new_vsfile_hgei); + + /* + * TODO: Modify the relevant translation tables at all IOMMUs so that = MSIs + * for this virtual interrupt file are now sent to the new physi= cal + * interrupt file. + */ + if ( iommu_enabled ) + printk_once("IMSIC: IOMMU MSI retargeting is not implemented\n"); + + /* + * If any interrupts at an APLIC are forwarded by MSIs to the old inte= rrupt + * file, reconfigure the APLIC to send them to the new interrupt file. + */ + aplic_reconfigure_target(v, old_vsfile_id, old_vsfile_cpu); + + /* + * Synchronizing interactions between a hart and the APLIC. + * + * The MSIs to be flushed are the ones still on their way to the old + * interrupt file, so the barrier has to be done by the pCPU which owns + * that file. + */ + imsic_call_on_cpu(old_vsfile_cpu, imsic_aplic_sync, NULL); + + /* + * At this point, all interrupt producers have been moved + * to the new IMSIC VS-file. + */ + BUG_ON("unimplemented"); } diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/as= m/imsic.h index 6ea2e4b8ca12..6395b539c52d 100644 --- a/xen/arch/riscv/include/asm/imsic.h +++ b/xen/arch/riscv/include/asm/imsic.h @@ -114,12 +114,15 @@ void imsic_ids_local_delivery(bool enable); int vcpu_imsic_init(struct vcpu *v); void vcpu_imsic_deinit(struct vcpu *v); unsigned int vcpu_guest_file_id(const struct vcpu *v); +void imsic_update_state(struct vcpu *v, unsigned int guest_file_id); =20 int vimsic_make_domu_dt_node(struct kernel_info *kinfo, unsigned int *phan= dle); =20 void imsic_ctxt_switch_from(struct vcpu *v); void imsic_ctxt_switch_to(struct vcpu *v); =20 +int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id); + void imsic_migrate_vcpu(struct vcpu *v); =20 #endif /* ASM_RISCV_IMSIC_H */ --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844187; cv=none; d=zohomail.com; s=zohoarc; b=glcMX7mjxvWXa7A7qeQdRdwc9n9cZls9+TeSsTI5TbpfeBbqnY3NFNH3YbPji2HxUW9qAuLpHpIjvB/BvKM+L/uWdcgSk/TfjrzTTgotuslqgYS8H9wEWieTlcIXOo43nPWC9YTCeS4P5I5X+sFU6rsyDTLYELS4XmJS6+PJ67A= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844187; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=0//RHN5teb/aonJ8KehG52cwEFGdViT/ExIm4kCxGVg=; b=Ir675Y6K0BefQftf44EIlWi2gEK+ePypE85eJIe0VVAJYEsWj7Yn2VhDGNO1b8xbdXYT9dBDFRVRECsFHskIgqlqt3Gd5iLlEoOmuM7ktMEmBkwdegP9LXptMRpzI+G/YCCBN7QmLdMSKmyY6IJ0LqBDNqdc4NnJOEd/ibaiSgI= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844187956857.1206914340232; Thu, 27 Aug 2026 08:23:07 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1401009.1636810 (Exim 4.92) (envelope-from ) id 1wzbwA-00006p-Qc; Thu, 27 Aug 2026 15:22:42 +0000 Received: by outflank-mailman (output) from mailman id 1401009.1636810; Thu, 27 Aug 2026 15:22:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbw9-0008US-NV; Thu, 27 Aug 2026 15:22:41 +0000 Received: by outflank-mailman (input) for mailman id 1401009; Thu, 27 Aug 2026 15:22:32 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbvz-0006bU-Pi for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:31 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbvz-009l5h-32 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:31 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a905633-8faa-0a2a0a5109dd-0a2a450293fc-12 for ; Thu, 27 Aug 2026 17:22:31 +0200 Received: from [209.85.128.46] (helo=mail-wm1-f46.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a905636-6ca4-0a2a45020019-d155802ef0da-3 for ; Thu, 27 Aug 2026 17:22:31 +0200 Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4953e04ef16so22304785e9.2 for ; Thu, 27 Aug 2026 08:22:31 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:29 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844150; x=1788448950; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=0//RHN5teb/aonJ8KehG52cwEFGdViT/ExIm4kCxGVg=; b=m4GNtS/gG8McI8U0ba2BWBe1I2Kq90b6vaUDoTnpsGZ3ki+iagU4zgnzSDf5S8vyxy zvBBtALT45Tw9bPlB38nrHXTToiqqpXECuitygSZCCJLDP1Bdu/2Jn8H4zIAFTp3EIQX ru/yS2AZiu20hofSk1JEYeytZN/J9iECChXqLydSaVkpH6eLA0/Sx2aDs0+Ep0avVC6Y +t/otXS69jYlFjUJs+AoIMJX2QL2tg1zsi1FcreVNugzRnMLJAiIvnEk+QF/UbttEc7W 0ebOSsi33j+an1nmV+qutl+HfMErGwKFcUvv4KSD0R941QPhgJksmhOFPF7OOa3BiKtG YPdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844150; x=1788448950; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=0//RHN5teb/aonJ8KehG52cwEFGdViT/ExIm4kCxGVg=; b=f+NMX+YHGnoa/iYsT2vWcZfn+6b0FvII0QdZ46/4FVc5ojcp8nHRFSaL4p1+P+Ym0i F8ogLjY6JJIGVl0MLhVYA50lvFO0V/+RvDweduua8AaOEyEAxuOH8DP2NvDvcaYxg7C8 9FlrOKmVMcuQfEXLQJAkmzS6NQnLnjSeKMRFX6rYhnkUuYgCgKj6fHn/a+8vPT0oUn7H gEsuhENV+xa4dGliDgXI8F74YJ9IlYHfz1aKyqbDhsJuFjMqMRSUTTEIOTRvcYT+CuYu IGkR0rcx65sQufpekW2adzqGziF186lEC+Goz2B+inQpuvmgjYL2Y0y5f2u7aVXfPucH So2g== X-Gm-Message-State: AFuF++k8OAT0QDUaupj04qsnGXFpGlH5ou/CQB/eX/9wvmuEmabFy6wE INa7+aP2j9RYVq6txtgRgSnxN8gAkUbJ6ebcLCrMF9nECS0z1B2lTFyumLIGaw== X-Gm-Gg: AR+sD13Wa9dxTErHauqZDiFUC0/u1REB0jo89KylFP4c7Vji7A1oWXrceCYxr0YJrQn edTueF3pB4fHQIaUmKN6ab6NC4EDSP/aiZ+y4LfdR9VpmtP+ADqytBDFF2Fi9s+Nn3RlmbWAWGM jW5h9Gi99Wl3Q6+j7qroJh/JrWC0owmHnXlqoVn94kX7V4Tv4A8jwVbw8OHHiqlBUQ0D0skXZfG T0EEvFy36Zi9sVP7n+AEUfOAEDUeKRTocbSB8sryQMYS+XzucsZreqfqlwhuwJiZiGOS8/DpOVn igK2hOnmNof4QvRGOIWdmE0VWal3Pahk5Pk5I5b/R14968dQq05/d4HJYF95cmZASB/4aT+0tWv XY36N7mabkBqUoxxOcwrCGUEh0VsRK4zcJtOOrls/cqgbNCQq3t1kUcBrkAR62/4lD9GfZ5RfT4 pWlbGep6dBv/vwCZchebZc2EVHzBIqJA7lQB+sUIWuH5+fSmcPVyGW1yFHFl06kDHldexaN3Sjb PguJ1tbGajhVAg3aLUxtQhkE/k+BR+5 X-Received: by 2002:a05:600c:468a:b0:499:726b:7375 with SMTP id 5b1f17b1804b1-499dc8272b1mr170929165e9.14.1787844150273; Thu, 27 Aug 2026 08:22:30 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 33/39] xen/riscv: dump old interrupt file to memory Date: Thu, 27 Aug 2026 17:21:17 +0200 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-720697/1787844151-307C22AC-E86F7F90/10/73395122804 X-purgate-type: spam X-purgate-size: 6857 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844188542158501 Content-Type: text/plain; charset="utf-8" At the old interrupt file, dump to memory all the eip and eie arrays). After this step is done, the old interrupt file is no longer in use so old intrrupt file VGEIN could be released. Restoring of old interrupt file state will be done in follow-up patch. There are cases where it is needed to specify on which cpu it is necessary to VGEIN should be released so update vgein_release() to deal with that. Keep BUG_ON("unimplemented") placeholder in imsic_migrate_vcpu() to guard against silent incorrect behaviour or unexpected panics in guest VMs until the function is fully implemented. vgein_release() is stub for now and will be introduced later. Signed-off-by: Oleksii Kurochko --- Changes in v2: - New patch. --- --- xen/arch/riscv/aia.c | 5 ++ xen/arch/riscv/imsic.c | 104 +++++++++++++++++++++++++++++++ xen/arch/riscv/include/asm/aia.h | 1 + 3 files changed, 110 insertions(+) diff --git a/xen/arch/riscv/aia.c b/xen/arch/riscv/aia.c index 75c82bcfa1b3..be3901ec0cfa 100644 --- a/xen/arch/riscv/aia.c +++ b/xen/arch/riscv/aia.c @@ -30,3 +30,8 @@ unsigned int vgein_assign(struct vcpu *v) =20 return 0; } + +void vgein_release(struct vcpu *v, unsigned int vgein_id, unsigned int cpu) +{ + BUG_ON("unimplemented\n"); +} diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c index 5e9f6995e443..3cba58e0c1b3 100644 --- a/xen/arch/riscv/imsic.c +++ b/xen/arch/riscv/imsic.c @@ -56,6 +56,24 @@ static unsigned int __ro_after_init guest_num_msis; */ #define GUEST_IMSIC_MAX_MSIS 255U =20 +/* + * The interrupt identities an IMSIC interrupt file provides are 0 (which = is + * never valid, but still occupies a bit) up to IMSIC_MAX_ID inclusive, so + * IMSIC_MAX_ID + 1 bits have to be covered. + */ +#define IMSIC_MAX_EIX DIV_ROUND_UP(IMSIC_MAX_ID + 1, BITS_PER_TYPE(uint64_= t)) + +struct imsic_mrif_eix { + unsigned long eip[BITS_PER_TYPE(uint64_t) / BITS_PER_LONG]; + unsigned long eie[BITS_PER_TYPE(uint64_t) / BITS_PER_LONG]; +}; + +struct imsic_mrif { + struct imsic_mrif_eix eix[IMSIC_MAX_EIX]; + unsigned long eithreshold; + unsigned long eidelivery; +}; + #define IMSIC_DISABLE_EIDELIVERY 0 #define IMSIC_ENABLE_EIDELIVERY 1 #define IMSIC_DISABLE_EITHRESHOLD 1 @@ -85,6 +103,15 @@ do { \ csr_clear(CSR_SIREG, v); \ } while (0) =20 +#define imsic_vs_csr_swap(c, v) \ +({ \ + unsigned long r_; \ + \ + csr_write(CSR_VSISELECT, (c)); \ + r_ =3D csr_swap(CSR_VSIREG, (v)); \ + r_; \ +}) + #define imsic_vs_csr_write(c, v) \ do { \ csr_write(CSR_VSISELECT, (c)); \ @@ -130,6 +157,21 @@ do { \ imsic_switchcase_32(F, ireg + 0, ##__VA_ARGS__) \ imsic_switchcase_32(F, ireg + 32, ##__VA_ARGS__) =20 +static unsigned long imsic_eix_swap(unsigned int ireg, unsigned long val) +{ + switch ( ireg ) + { + imsic_switchcase_64(imsic_switchcase_ret, IMSIC_EIP0, + imsic_vs_csr_swap, val) + imsic_switchcase_64(imsic_switchcase_ret, IMSIC_EIE0, + imsic_vs_csr_swap, val) + default: + ASSERT_UNREACHABLE(); + } + + return 0; +} + static void imsic_eix_write(unsigned int ireg, unsigned long val) { switch ( ireg ) @@ -577,6 +619,61 @@ static void cf_check imsic_vsfile_local_clear(void *da= ta) csr_write(CSR_VSISELECT, old_vsiselect); } =20 +static void cf_check imsic_vsfile_local_read_clear(void *data) +{ + unsigned int i; + struct imsic_mrif_eix *eix; + const struct imsic_vsfile_data *idata =3D data; + struct imsic_mrif *mrif =3D idata->mrif; + unsigned long new_hstatus, old_hstatus, old_vsiselect; + + old_vsiselect =3D csr_read(CSR_VSISELECT); + old_hstatus =3D csr_read(CSR_HSTATUS); + new_hstatus =3D old_hstatus & ~HSTATUS_VGEIN; + new_hstatus |=3D ((unsigned long)idata->hgei) << HSTATUS_VGEIN_SHIFT; + csr_write(CSR_HSTATUS, new_hstatus); + + /* + * There is no need to use atomic functions version to store + * values in MRIF because imsic_vsfile_read_clear() is always called + * with pointer to temporary MRIF on stack. + */ + + mrif->eidelivery =3D imsic_vs_csr_swap(IMSIC_EIDELIVERY, 0); + mrif->eithreshold =3D imsic_vs_csr_swap(IMSIC_EITHRESHOLD, 0); + for ( i =3D 0; i < idata->nr_eix; i++ ) + { + eix =3D &mrif->eix[i]; + eix->eip[0] =3D imsic_eix_swap(IMSIC_EIP0 + i * 2, 0); + eix->eie[0] =3D imsic_eix_swap(IMSIC_EIE0 + i * 2, 0); +#ifdef CONFIG_RISCV_32 + eix->eip[1] =3D imsic_eix_swap(IMSIC_EIP0 + i * 2 + 1, 0); + eix->eie[1] =3D imsic_eix_swap(IMSIC_EIE0 + i * 2 + 1, 0); +#endif + } + + csr_write(CSR_HSTATUS, old_hstatus); + csr_write(CSR_VSISELECT, old_vsiselect); +} + +static void imsic_vsfile_read_clear(unsigned int vsfile_id, + unsigned int vsfile_cpu, + unsigned int nr_eix, + struct imsic_mrif *mrif) +{ + struct imsic_vsfile_data idata =3D { + .hgei =3D vsfile_id, + .nr_eix =3D nr_eix, + .mrif =3D mrif, + }; + + /* We can only read clear if we have a IMSIC VS-file */ + if ( vsfile_cpu =3D=3D NR_CPUS || !vsfile_id ) + return; + + imsic_call_on_cpu(vsfile_cpu, imsic_vsfile_local_read_clear, &idata); +} + void cf_check vcpu_imsic_deinit(struct vcpu *v) { XVFREE(v->arch.vimsic_state); @@ -888,6 +985,7 @@ void imsic_migrate_vcpu(struct vcpu *v) unsigned long flags; unsigned int old_vsfile_id; unsigned int old_vsfile_cpu; + struct imsic_mrif tmrif =3D { }; =20 /* * The scheduler can mark a freshly created vCPU's unit as migrated and @@ -973,5 +1071,11 @@ void imsic_migrate_vcpu(struct vcpu *v) * to the new IMSIC VS-file. */ =20 + /* Read and clear register state from old IMSIC VS-file */ + imsic_vsfile_read_clear(old_vsfile_id, old_vsfile_cpu, nr_hw_eix, &tmr= if); + + /* Free-up old IMSIC VS-file */ + vgein_release(v, old_vsfile_id, old_vsfile_cpu); + BUG_ON("unimplemented"); } diff --git a/xen/arch/riscv/include/asm/aia.h b/xen/arch/riscv/include/asm/= aia.h index 53a1efb042f8..8e4eb2f6b14e 100644 --- a/xen/arch/riscv/include/asm/aia.h +++ b/xen/arch/riscv/include/asm/aia.h @@ -10,5 +10,6 @@ bool aia_usable(void); void aia_init(void); =20 unsigned int vgein_assign(struct vcpu *v); +void vgein_release(struct vcpu *v, unsigned int vgein_id, unsigned int cpu= ); =20 #endif /* RISCV_AIA_H */ --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844184; cv=none; d=zohomail.com; s=zohoarc; b=Cph2gF9+Yaz/XUVU6eXi8HLcoAt5I8LnMj0yuudVRz9frxNr75CybthnaGOwxkdkU+LuvhLrjZp7mka6cmMtPNoXM2zAaG8VUjXGNMAtrKikIF8GKTPC+AVfK7IEpmCcEMcp3DR8bVy0ot3tSB7n+KcaeEy/5I2fUfsx6/Brb4Y= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844184; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=mcjTrPtVn6obyw8+MchPLEcLSGsG8pZjB+QFS0E6TVo=; b=b3ueLfS96rKMotAnY7rDPJ1x6cBcEo5ts5w1TFi+XYascchvfTt7NcvyIB1vK4qGVmksUfd+8+X1vScj+bEe/2iZ9iBCNnhE7hdWXSERznChdVFcCeJSX1qvtxIMuRGBFODfJXatDcgXSt9J8OUKXhWIf7KqeOPqbGgoko0dJJU= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844184440196.58681317264086; Thu, 27 Aug 2026 08:23:04 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1401014.1636818 (Exim 4.92) (envelope-from ) id 1wzbwC-0000YX-I5; Thu, 27 Aug 2026 15:22:44 +0000 Received: by outflank-mailman (output) from mailman id 1401014.1636818; Thu, 27 Aug 2026 15:22:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbwB-0000RA-Gn; Thu, 27 Aug 2026 15:22:43 +0000 Received: by outflank-mailman (input) for mailman id 1401014; Thu, 27 Aug 2026 15:22:33 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbw0-0006rs-Qk for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:32 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbw0-00GwFq-6z for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:32 +0200 Received: from [10.42.69.12] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a90561f-bab6-0a2a0a5309dd-0a2a450cb996-38 for ; Thu, 27 Aug 2026 17:22:32 +0200 Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com) by tlsNG-d25034.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a905638-f479-0a2a450c0019-d1558034c5b9-3 for ; Thu, 27 Aug 2026 17:22:32 +0200 Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-49b8ce9b733so6305435e9.1 for ; Thu, 27 Aug 2026 08:22:32 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:31 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844151; x=1788448951; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=mcjTrPtVn6obyw8+MchPLEcLSGsG8pZjB+QFS0E6TVo=; b=I0bYtzCupjrFQcs9xFiubK8TrRf5wEVE62fE9N8syWByNtnYKESrcZ8LXFKrJkWdYb JekH2uhHU15PBtPGxOJ0A9CYgYs4t2JXgCPDWlUjc14PSM1ajt7zFn7AqoBbx1RUC63r X2cahEu/91pzYDd2hE3ZbQPBbYKwLKSgesERnhYXYuv0JX3kn3gPGxKGR2kKx1LBrRD8 jreuADcK7Ghzh0LI8FiXKLSljHYdyuBgwM0l9dbck7q/gVNqFhMpagt7QQA+G3zcl3QM CWjtzREnyjZjUNCzPr59cCVm+IWnRn5ZAA6oC+e9ZddQuKlag6q9LYEBZxc7CostgTCP MUvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844151; x=1788448951; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=mcjTrPtVn6obyw8+MchPLEcLSGsG8pZjB+QFS0E6TVo=; b=OUiUhZm/qWDeh4NTEJy1wQwyUsHxu46BpyfUj+PaS+uGonEzhru9kMyFsx6GN47uvr 1OsTDimgkBdAVkhKahBbSNDApn2BgTHadizLOSpOf9pZ5lRrNiZm/w6prfp618D1iH11 Dxm+6MIFRLeXnghCEbzP75viHSXbpQJiir1qN5G8LI92nijmupnBoVcYMoBStHghP4D1 X7iOL0N2GPrgsQ6aM7R7PZ+1lmG0fGArpYAjrnQziHXvIsDqzQC+F1sCCV0gH43YWVGF R1hv/RTmg1nJmlip6LRblaKjIHLQPsKrd5lgiTlXgCZsEkCSlQxB7JfcIBaSzDChHCpy Cqww== X-Gm-Message-State: AFuF++mQZcTFG3BFAZ1FoNY/9vCunlxWxp6hPuv/4aXY3faM/KOWgFH+ Mey01zzjGmBRNHtZNb/iE7UGvhn8N3MvmCgeC2BFupQu7XnubFxcUG4VDrNDXQ== X-Gm-Gg: AR+sD11OX1wDanragoAvMoslWl9WMls+oLC5pjIbO75xVligy9tjp+qbd3HjJ01xQU6 9Q996M73mfLhlM7Hq/KBVKZpveTMIm+iOwovibF52psMwWiZlulN3WhcJztxakpMW283T1asS5h KnewjiauGDjQVNLBBVgv/NTe7Q0XaBKCyTseJ3Uaxa7mHOe0jZQhNYhgJVoXPXL30LAXBBIcyH9 xW1wgMAxBQXeEqO/QL3WMljrKsYawPZELjDmP8S55PRO+ad2wVWOb2cD2qH+O2n4/NbF1ynMa8F TzvYNWNUjDKUpRatlZS180KnXbOWOkD5u/c2yQaRNdz6v9vRFNQ5DmK7kjjOK3DJ7atxMbUlZMw sKZ2OM0DYBZT0hMRLumNtJ07A1PNeIne/81RGpjiuDnMeneV0G+cCFHfb6bHK70c/kKd1rgsdFT wHtIhwNpS1+idxrhQIslC3zUWVkIBLakQBCrivCysZIU7LUrVKW0RLOGveAN/pdfPAbNE6uPyBJ t9M8c4haTt5kukPr4SmN6Nj6vZ/qz4gZA== X-Received: by 2002:a05:600c:a0d:b0:499:bdf1:7578 with SMTP id 5b1f17b1804b1-499dc6e9b00mr194879995e9.3.1787844151536; Thu, 27 Aug 2026 08:22:31 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 34/39] xen/riscv: restore register state in the new IMSIC VS-file Date: Thu, 27 Aug 2026 17:21:18 +0200 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d25034/1787844152-034D7A5B-887023BB/10/73395122804 X-purgate-type: spam X-purgate-size: 5244 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844186524158500 Content-Type: text/plain; charset="utf-8" At this point, all interrupt producers have been moved to the new IMSIC VS-file so we move register state from the old IMSIC VS/SW-file to the new IMSIC VS-file. As new IMSIC VS-file is ready to be used update vCPU's hstatus with new VGEIN. As the whole migration procedure is finished add some extra explanatory comments. Signed-off-by: Oleksii Kurochko --- Changes in v2: - New patch. --- --- xen/arch/riscv/imsic.c | 82 ++++++++++++++++++++++++++++++++++++++---- 1 file changed, 76 insertions(+), 6 deletions(-) diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c index 3cba58e0c1b3..d7b137a1f559 100644 --- a/xen/arch/riscv/imsic.c +++ b/xen/arch/riscv/imsic.c @@ -112,6 +112,12 @@ do { \ r_; \ }) =20 +#define imsic_vs_csr_set(c, v) \ +do { \ + csr_write(CSR_VSISELECT, (c)); \ + csr_set(CSR_VSIREG, (v)); \ +} while ( 0 ) + #define imsic_vs_csr_write(c, v) \ do { \ csr_write(CSR_VSISELECT, (c)); \ @@ -185,6 +191,19 @@ static void imsic_eix_write(unsigned int ireg, unsigne= d long val) } } =20 +static void imsic_eix_set(unsigned int ireg, unsigned long val) +{ + switch ( ireg ) + { + imsic_switchcase_64(imsic_switchcase_break, IMSIC_EIP0, + imsic_vs_csr_set, val) + imsic_switchcase_64(imsic_switchcase_break, IMSIC_EIE0, + imsic_vs_csr_set, val) + default: + ASSERT_UNREACHABLE(); + } +} + unsigned int vcpu_guest_file_id(const struct vcpu *v) { return ACCESS_ONCE(v->arch.vimsic_state->guest_file_id); @@ -630,13 +649,13 @@ static void cf_check imsic_vsfile_local_read_clear(vo= id *data) old_vsiselect =3D csr_read(CSR_VSISELECT); old_hstatus =3D csr_read(CSR_HSTATUS); new_hstatus =3D old_hstatus & ~HSTATUS_VGEIN; - new_hstatus |=3D ((unsigned long)idata->hgei) << HSTATUS_VGEIN_SHIFT; + new_hstatus |=3D MASK_INSR(idata->hgei, HSTATUS_VGEIN); csr_write(CSR_HSTATUS, new_hstatus); =20 /* - * There is no need to use atomic functions version to store - * values in MRIF because imsic_vsfile_read_clear() is always called - * with pointer to temporary MRIF on stack. + * No atomic accessors are needed to store the values into the MRIF he= re, + * as imsic_vsfile_read_clear() is always called with a pointer to a + * temporary MRIF on the stack. */ =20 mrif->eidelivery =3D imsic_vs_csr_swap(IMSIC_EIDELIVERY, 0); @@ -972,6 +991,49 @@ int __init vimsic_make_domu_dt_node(struct kernel_info= *kinfo, return fdt_end_node(fdt); } =20 +static void cf_check imsic_vsfile_local_update(void *data) +{ + unsigned int i; + struct imsic_mrif_eix *eix; + const struct imsic_vsfile_data *idata =3D data; + struct imsic_mrif *mrif =3D idata->mrif; + unsigned long new_hstatus, old_hstatus, old_vsiselect; + + /* We can only update if we have a HW IMSIC context */ + if ( !idata->hgei ) + return; + + /* + * No atomic accessors are needed to read the values out of the MRIF h= ere, + * as this is always called with a pointer to a temporary MRIF on the + * stack. + */ + + old_vsiselect =3D csr_read(CSR_VSISELECT); + old_hstatus =3D csr_read(CSR_HSTATUS); + new_hstatus =3D old_hstatus & ~HSTATUS_VGEIN; + new_hstatus |=3D MASK_INSR(idata->hgei, HSTATUS_VGEIN); + csr_write(CSR_HSTATUS, new_hstatus); + + for ( i =3D 0; i < idata->nr_eix; i++ ) + { + eix =3D &mrif->eix[i]; + + imsic_eix_set(IMSIC_EIP0 + i * 2, eix->eip[0]); + imsic_eix_set(IMSIC_EIE0 + i * 2, eix->eie[0]); +#ifdef CONFIG_RISCV_32 + imsic_eix_set(IMSIC_EIP0 + i * 2 + 1, eix->eip[1]); + imsic_eix_set(IMSIC_EIE0 + i * 2 + 1, eix->eie[1]); +#endif + } + + imsic_vs_csr_write(IMSIC_EITHRESHOLD, mrif->eithreshold); + imsic_vs_csr_write(IMSIC_EIDELIVERY, mrif->eidelivery); + + csr_write(CSR_HSTATUS, old_hstatus); + csr_write(CSR_VSISELECT, old_vsiselect); +} + void imsic_migrate_vcpu(struct vcpu *v) { unsigned int new_vsfile_hgei; @@ -1068,7 +1130,8 @@ void imsic_migrate_vcpu(struct vcpu *v) =20 /* * At this point, all interrupt producers have been moved - * to the new IMSIC VS-file. + * to the new IMSIC VS-file so we move register state from + * the old IMSIC VS/SW-file to the new IMSIC VS-file. */ =20 /* Read and clear register state from old IMSIC VS-file */ @@ -1077,5 +1140,12 @@ void imsic_migrate_vcpu(struct vcpu *v) /* Free-up old IMSIC VS-file */ vgein_release(v, old_vsfile_id, old_vsfile_cpu); =20 - BUG_ON("unimplemented"); + /* Restore register state in the new IMSIC VS-file */ + vsfile_data.mrif =3D &tmrif; + imsic_call_on_cpu(new_vsfile_cpu, imsic_vsfile_local_update, &vsfile_d= ata); + + /* Set VCPU HSTATUS.VGEIN to new IMSIC VS-file */ + vcpu_guest_cpu_user_regs(v)->hstatus &=3D ~HSTATUS_VGEIN; + vcpu_guest_cpu_user_regs(v)->hstatus |=3D + MASK_INSR(new_vsfile_hgei, HSTATUS_VGEIN); } --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844185; cv=none; d=zohomail.com; s=zohoarc; b=NzPzd1t7glzXYTRoi0r3hlHXlYGw8PpJ/glB9HBVDEEPWPYXHcxQEcfAjIwNCXUfZjAOnKpOCZUnX85mbisbsRw+GooZYpIAWtcyGfAWtz0ScfbH4nrNIa4wR4Zh6ylSMPI4e/54ZFMAfpjdSZdYkaU2OTo8JYCjakWIg8ottKA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844185; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=PgOt6oP0YSRzyLwFjuW3JpsOMyWOpqs2dYdG8JVXlwE=; b=EWVZb7sDOor/Wibh+1OSqIfQ/LoAT+61o5cjffVYKog/0EfPrzrWeA3BJBiDhVZiYBV4NxTt7joOQ3Xeudg8nhKqJ+iWzWuG+frno9tHr6/IDrHGq7lvE8JUzKtmbt4MhkWPSV0rish732hR9zJtWqTo/Y9pOpWZx/pSCpPm55o= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844185473316.859249297633; Thu, 27 Aug 2026 08:23:05 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1401020.1636831 (Exim 4.92) (envelope-from ) id 1wzbwG-0001Kk-73; Thu, 27 Aug 2026 15:22:48 +0000 Received: by outflank-mailman (output) from mailman id 1401020.1636831; Thu, 27 Aug 2026 15:22:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbwF-0001EF-0S; Thu, 27 Aug 2026 15:22:47 +0000 Received: by outflank-mailman (input) for mailman id 1401020; Thu, 27 Aug 2026 15:22:35 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbw2-00079A-1v for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:34 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbw1-009l31-C2 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:33 +0200 Received: from [10.42.69.3] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a905628-2eae-0a2a0a5409dd-0a2a4503e5b2-22 for ; Thu, 27 Aug 2026 17:22:33 +0200 Received: from [209.85.221.45] (helo=mail-wr1-f45.google.com) by tlsNG-33051d.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a905639-fae8-0a2a45030019-d155dd2dc5a1-3 for ; Thu, 27 Aug 2026 17:22:33 +0200 Received: by mail-wr1-f45.google.com with SMTP id ffacd0b85a97d-47fe2d179e2so1401547f8f.1 for ; Thu, 27 Aug 2026 08:22:33 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:32 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844153; x=1788448953; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=PgOt6oP0YSRzyLwFjuW3JpsOMyWOpqs2dYdG8JVXlwE=; b=V5DvxfCCtiu1+X6FWUFaCKwfUjwXqqRJklttb9sYXqNz5kMtIna/taIbYvdn3UeVih BuR2U3WwhWdErKPCqnaIwmc/ULEHCEq9s4jChmgd5lhSfVKHHxq/dqv4Ira66kY9/ZlL 5CRa4Q9hIA/vv7yAn4E6cTzGclEyr95QYyc/pCi6v6ao42vGb2AbLpf+gBazdegds/b+ oPb8EfrDyzkUihECSi+nsJ0DwszIip/fUQwjiFjB5Vj30D6L2qRiMB6lnZZEUc1EQi5a W8HVwejoNgoMMCiaAWPSzJRFWb730JGp0s6KJwiE3FImngFVHwk6+JGx8VyHZ7tP3a6A dzPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844153; x=1788448953; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=PgOt6oP0YSRzyLwFjuW3JpsOMyWOpqs2dYdG8JVXlwE=; b=Fm0tM2Rj50BCq6xjKzW13+y0N29yiPiqErfrbrliYdVvj00/1xhTEhu9PrB+EgsQHC 5blgJq/BMwZ01uUPG4LN4mnLT9uR1qizCtLcw5SfX2IJPNaf1OIwmRl/A9/sxqHmru8r /Ko8de0tB3Pox5Wx404vYc5x+RizbuDzLMfWYT7fFO/8j+tigGSRT8G+63dCdII290F6 Jn6+ynd1/+1q0HtQnGAqqCQl5MOl6bgEGWDDYjCqdLF5ipJmS4ajyM0DVM7YhDqZM8yY nUwCZfrVTAGr8MsxaElu7UsqUexqUVSbNCFSM72Q2oPYUyhCLOQDkSUuJnqRxH3howHN sOJg== X-Gm-Message-State: AFuF++k+ws6l9iRmDyZKrwedgaBegslydBTtZf6I9CVvhbibtGHRL6QD 7TIEotqdQTexMfHEZQOxD88FkyRMzqCxjPaCed4tx9Bm+WN0efnI1Xx6IJBjxw== X-Gm-Gg: AR+sD13PAWFpXHiRlBrbGFTkmH/afXbLTKTe2AXjuUjEPriEvGZhakSEOSd2mXqQV1S AOxqwGIyaVY8S93qq3rqMj3YiXuNdQBErIQyGRDh9eOeaAfWOVIlWMqHF69NPbKDkOLLYelkfLJ UTxdZg3eU665qFy+MhMz7EdW6rLsLHjUNoXTVzIfKTTIlmp3cVli4XJaDDCLLPXlkGAIFVX/dkl 04ohHQK05qZ3Ry7ykr8FoAXcqqYdCymOru5GNNN7obaShxdhITkemwCvucP4csBNLTASY/opcR5 IUobYA3qNmmpD3Tf7vCaHjKvis+XGADlCoK4SIDihtP+XORvk9YQa+GUP6Fpabg5do8axoTrD1k xFCosj3/llUNEdZeBvIRX+gbdJD0ITQPkjZLL5gcnDb/+SI27WsV3yQCdnQVaMh6RjsdNn6QQke opZ9fb02zBl4BcxHlG1FfPM42UyXoDi8dg5w8+HGcPmSeJRi+aEx9nnULLmmoC+o6tm/njjfmfT f+PhU4yyCvULK9j4D8Mu9cDustsy9VJeGw+TDBqli4= X-Received: by 2002:a05:600c:4514:b0:499:8777:ccba with SMTP id 5b1f17b1804b1-499dc822557mr185139295e9.12.1787844152732; Thu, 27 Aug 2026 08:22:32 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 35/39] xen/riscv: add basic VGEIN management for AIA guests Date: Thu, 27 Aug 2026 17:21:19 +0200 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-33051d/1787844153-74A894E9-9526A485/10/73395122804 X-purgate-type: spam X-purgate-size: 6453 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844186545158500 Content-Type: text/plain; charset="utf-8" It was decided to add support for IMSIC from the start instead of having AP= LIC operate in direct delivery mode, as it requires a trap-and-emulation approa= ch, which is not optimal from a performance standpoint. AIA provides a hardware-accelerated mechanism for delivering external interrupts to domains via "guest interrupt files" located in IMSIC. A single physical hart can implement multiple such files (up to GEILEN), allowing several virtual harts to receive interrupts directly from hardware. Introduce per-CPU tracking of guest interrupt file identifiers (VGEIN) for systems implementing AIA specification. Each CPU maintains a bitmap describing which guest interrupt files are currently in use. Implement helpers to initialize the bitmap based on the number of available guest interrupt files (GEILEN), assign a VGEIN to a vCPU, and release it when no longer needed. Signed-off-by: Oleksii Kurochko --- Also in the next patch there is other context to understand the usage of spinlock introduced here. --- Changes in v2: - make vgein_init() pCPU agnostic as it is working with CSR which could be read only on local pCPU itself. - Move introduction of vgein_ctrl->owners[] to separate patch. - Add ASSERT() and re-init vgein->bmp with 0. - Update the commit message (drop the last sentence as ->hstatus isn't filled anymore in in vgein_*() functions). - Introduce vgein_deinit(). --- --- xen/arch/riscv/aia.c | 141 +++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 137 insertions(+), 4 deletions(-) diff --git a/xen/arch/riscv/aia.c b/xen/arch/riscv/aia.c index be3901ec0cfa..1aca07c2f70f 100644 --- a/xen/arch/riscv/aia.c +++ b/xen/arch/riscv/aia.c @@ -1,13 +1,31 @@ /* SPDX-License-Identifier: GPL-2.0-only */ =20 -#include +#include +#include #include #include #include #include +#include #include =20 +#include #include +#include +#include + +struct vgein_ctrl { + /* The least-significant bits are implemented first, apart from bit 0 = */ + unsigned long bmp; + spinlock_t lock; + unsigned int geilen; +}; + +/* + * VGEIN control structure for each physical CPU to track which VS (guest) + * interrupt file IDs are in use. + */ +static DEFINE_PER_CPU(struct vgein_ctrl, vgein); =20 static bool __ro_after_init _aia_usable; =20 @@ -16,22 +34,137 @@ bool aia_usable(void) return _aia_usable; } =20 +/* HGEIE is a per-hart CSR, so this has to run on the CPU being initialize= d. */ +static int vgein_init(void) +{ + struct vgein_ctrl *vgein =3D &this_cpu(vgein); + + spin_lock_init(&vgein->lock); + + csr_write(CSR_HGEIE, ~0UL); + vgein->geilen =3D flsl(csr_read(CSR_HGEIE) >> 1); + csr_write(CSR_HGEIE, 0); + + vgein->bmp =3D 0; + + if ( !vgein->geilen ) + return -EOPNOTSUPP; + + return 0; +} + +static void vgein_deinit(void) +{ + csr_write(CSR_HGEIE, 0); +} + +static int cf_check cpu_callback(struct notifier_block *nfb, + unsigned long action, void *hcpu) +{ + unsigned int cpu =3D (unsigned long)hcpu; + int rc =3D 0; + + switch ( action ) + { + case CPU_STARTING: + rc =3D vgein_init(); + if ( rc ) + printk(XENLOG_ERR "AIA: failed to init vgein for CPU%u: %d\n", + cpu, rc); + break; + + case CPU_DYING: + vgein_deinit(); + break; + } + + return notifier_from_errno(rc); +} + +static struct notifier_block cpu_nfb =3D { + .notifier_call =3D cpu_callback, +}; + void __init aia_init(void) { + int rc; + if ( !riscv_isa_extension_available(NULL, RISCV_ISA_EXT_ssaia) ) + { + dprintk(XENLOG_WARNING, "SSAIA isn't present in riscv,isa\n"); return; + } + + if ( (rc =3D vgein_init()) ) + { + dprintk(XENLOG_ERR, "vgein_init() failed: %d\n", rc); + return; + } =20 _aia_usable =3D true; + + register_cpu_notifier(&cpu_nfb); } =20 unsigned int vgein_assign(struct vcpu *v) { - BUG_ON("unimplemented\n"); + unsigned int vgein_id; + struct vgein_ctrl *vgein =3D &per_cpu(vgein, v->processor); + unsigned long *bmp =3D &vgein->bmp; + unsigned long flags; =20 - return 0; + if ( !vgein->geilen ) + return 0; + + spin_lock_irqsave(&vgein->lock, flags); + /* + * The vgein_id shouldn't be zero, as it will indicate that no guest + * external interrupt source is selected for VS-level external interru= pts + * according to RISC-V privileged spec: + * Hypervisor Status Register (hstatus) in RISC-V privileged spec: + * + * The VGEIN (Virtual Guest External Interrupt Number) field selects + * a guest external interrupt source for VS-level external interrupt= s. + * VGEIN is a WLRL field that must be able to hold values between ze= ro + * and the maximum guest external interrupt number (known as GEILEN), + * inclusive. + * When VGEIN=3D0, no guest external interrupt source is selected for + * VS-level external interrupts. + * + * So start to search from bit number 1. + */ + vgein_id =3D find_next_zero_bit(bmp, vgein->geilen + 1, 1); + + if ( vgein_id > vgein->geilen ) + vgein_id =3D 0; + else + __set_bit(vgein_id, bmp); + + spin_unlock_irqrestore(&vgein->lock, flags); + +#ifdef VGEIN_DEBUG + gprintk(XENLOG_DEBUG, "%s: %pv: vgein_id(%u), xen_cpu%u_bmp=3D%#lx\n", + __func__, v, vgein_id, v->processor, *bmp); +#endif + + return vgein_id; } =20 void vgein_release(struct vcpu *v, unsigned int vgein_id, unsigned int cpu) { - BUG_ON("unimplemented\n"); + unsigned long flags; + struct vgein_ctrl *vgein =3D &per_cpu(vgein, cpu); + + if ( !vgein_id ) + return; + + spin_lock_irqsave(&vgein->lock, flags); + if ( !__test_and_clear_bit(vgein_id, &vgein->bmp) ) + ASSERT_UNREACHABLE(); + spin_unlock_irqrestore(&vgein->lock, flags); + +#ifdef VGEIN_DEBUG + gprintk(XENLOG_DEBUG, "%s: %pv: vgein_id(%u), xen_cpu%u_bmp=3D%#lx\n", + __func__, v, vgein_id, cpu, vgein->bmp); +#endif } --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844201; cv=none; d=zohomail.com; s=zohoarc; b=jVAP9Pr/BbTmdMiTQjlnMM4pRjybchL+lLj0taTTvg95g9Qcgp/iK1tnl15srog1LUbylRbFUbt2gtZFGR41pqoC0ctb6ROZSjxLg+drw8ybEfzBNFQHyha714w1Fpa2a9LEKYw8FN5KNHSOlHJ06yHhDDcHeEogmSPMnHGm7So= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844201; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=2bqWbi5fbwW7bQ22v8Kh1i+e8YYjZtzF8u1P+wqOQN0=; b=jzNEgKxa25DGhZzfpECrXAcEB+r81qrmS8WIoCiraL250xE/k3Nijh4xp2M36IUFCpoL1vXGeZSImqH7OmRaCaU//oSyW51CBqpOCoTMbzA7rMMTEy80VLRA/cABqDm9Qxd3xwqx2UR/tJxbyvq/QNCNwdKsHwYdJi2iyLx/mMM= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844201843239.5823642373448; Thu, 27 Aug 2026 08:23:21 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1401025.1636841 (Exim 4.92) (envelope-from ) id 1wzbwH-0001b4-RE; Thu, 27 Aug 2026 15:22:49 +0000 Received: by outflank-mailman (output) from mailman id 1401025.1636841; Thu, 27 Aug 2026 15:22:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbwG-0001Wq-Dn; Thu, 27 Aug 2026 15:22:48 +0000 Received: by outflank-mailman (input) for mailman id 1401025; Thu, 27 Aug 2026 15:22:36 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbw3-0007Lt-GE for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:35 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbw2-003O3L-SN for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:34 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a905626-e002-0a2a0a5209dd-0a2a4501aa5e-26 for ; Thu, 27 Aug 2026 17:22:34 +0200 Received: from [209.85.128.52] (helo=mail-wm1-f52.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a90563a-5984-0a2a45010019-d1558034c120-3 for ; Thu, 27 Aug 2026 17:22:34 +0200 Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-49b8687630fso5778555e9.3 for ; Thu, 27 Aug 2026 08:22:34 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:33 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844154; x=1788448954; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=2bqWbi5fbwW7bQ22v8Kh1i+e8YYjZtzF8u1P+wqOQN0=; b=SdHcURTH82LQCd068xWLy7cZNwdfsWxdUUBqjmYJ7xvAuk1hICfQ5CrrcATRQSAn4D IviPGuNbX2rBnk8jlxV3b8RcSoM+vDI73V/li2vDAJhLtugzLSt9mP8BDEuFXTqPB4hE iaAMuZDnsNPZAxbU0O22TiFgPB6O9EpLubUByH0kmXa/t4aGC/966WFuGDSX7gazx2X3 p1m1hJtPu3P8UMIvSFBgV8FqryItame7eriCfQWy2hCi2l+zvFluGZ4OpvXhDzrbmtAQ xwVwyKGl8urRtibpnaa0HUc56ZnKmilexR7d/WT7HstBx/hSI63uKqPdWqoSQ6JPqAMt AVlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844154; x=1788448954; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=2bqWbi5fbwW7bQ22v8Kh1i+e8YYjZtzF8u1P+wqOQN0=; b=hFsk3rA/T+xE1OpVrwv7i1nzc1MUZpdwlYcfdjmPS3Bpy7zG+2jLJcSdPDgPd917bq oQlm93dPsJOzxfCxrcU0grLuSS8Ox3crbkWgNJvGpPS1QyY4yB1yfEAvRPIHVZ/TN6tN S6M9vjRs+Kvqu7f7Jpa+FkSZhen0mhgzyXfmt9fN3GfLPRE5G53fcQItHmzJs0seJYW4 PfaqrbUtpbWowYAI0oOCXXIqA+whVwaiTLwRL1iQqrgcXVgdWvKESy6XnGAhjm7StDuA frEhj56oAInS9GkSxiitaxrG1wvRKNqHR1+ADinwqcGZ6nplayPtChtshQiaUCi6Bya2 y2Rw== X-Gm-Message-State: AFuF++nJ4BfP4B37+WC2h+vHgQtOwPme+r6SBWznovVT2pswYp5m7D+Z GXfJ9CZqNztFd/N28+n04eSTsT30Olv+ZsQ8ETq2ey4OH45NrM4z5+ajodcNow== X-Gm-Gg: AR+sD130JRvKkZhfYFsMvFP9dCLO6dCk3XE0OOhCM4wROq++DvKLglmnEp31eHilqRt bt2G0dXML3sdAufPpcqwmlkf3+PPBJ6BhqcDA6a+eyONHLa3v7irRLKPTOA35b92hZWBBvpY1bw gscibEz2s7DOT6hszx5SWF5nkJp1ftTUf8AfMzoVTEQnOeo3LG0aW2gawM7aQxoVGLNpjo4W8K2 GoXvM+1dXowWiIBRZcqwlvTEM3alHVXSkYfmlftABcPRKkjqr9tYx/1F6ooIpkKXKxWK8rwMSvR Jk4gnboT/pntS3WM/V/WuZ0XzEMFGOxWYioN7Fh105whLcN29PBAyRKJhDmox1r65NGwc7pHrHK a4vxqJTu5Ysg9ElI81AHY+6tzz+gsac1bcVm5Q+fqdycsvRPaKyOcF+MJQD7GkgWMs6FzP6jFbV 9ax305TM1/A8JqBOZIK/tWMR6TmOBCF2IDvaek6TptXXT5n1OqNKkOXv8eABY6wPzGHmtziU2f+ uFxfK5k/uCYoSu6sz+6rUx8CAfPh3Mw X-Received: by 2002:a05:600c:a43:b0:497:fecd:5b00 with SMTP id 5b1f17b1804b1-499dc717e27mr174641215e9.9.1787844154137; Thu, 27 Aug 2026 08:22:34 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 36/39] xen/riscv: wake up a descheduled vCPU on a guest external interrupt Date: Thu, 27 Aug 2026 17:21:20 +0200 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d62444/1787844154-BEA66757-6A65D1A5/10/73395122804 X-purgate-type: spam X-purgate-size: 10845 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844202676158500 Content-Type: text/plain; charset="utf-8" While a vCPU is running, MSIs written to its h/w IMSIC guest interrupt file are delivered straight to VS-mode. Once the vCPU is descheduled nobody observes that file anymore, so a guest blocked on such an interrupt would stay blocked until some unrelated event happens to schedule it again. Let Xen observe the file in that window: on deschedule set the vCPU's bit in HGEIE, which turns an interrupt pending in its VS-file into an HS-level SGEI, and clear the bit again on schedule-in. HGEIP only reports a file number, so to get from it back to a vCPU keep an owners[] map per pCPU, filled by vgein_{assign,release} alongside the VGEIN bitmap, and kick the vCPU it points at. v->arch.hie is only initialized here and is written to the CSR later, on the context switch to the vCPU. vgein_release() still has no caller: a vCPU going away has to both free its VGEIN slot and drop the owners[] entry, but there is no vCPU teardown path to hook it into yet. vgein_deinit() only covers a pCPU going offline. Signed-off-by: Oleksii Kurochko --- Changes in v2: - New patch. --- --- xen/arch/riscv/aia.c | 52 +++++++++++++++++++++++++-- xen/arch/riscv/domain.c | 3 ++ xen/arch/riscv/imsic.c | 55 ++++++++++++++++++++++++++++- xen/arch/riscv/include/asm/aia.h | 2 ++ xen/arch/riscv/include/asm/domain.h | 1 + xen/arch/riscv/traps.c | 7 +++- 6 files changed, 115 insertions(+), 5 deletions(-) diff --git a/xen/arch/riscv/aia.c b/xen/arch/riscv/aia.c index 1aca07c2f70f..9642a9796ead 100644 --- a/xen/arch/riscv/aia.c +++ b/xen/arch/riscv/aia.c @@ -18,6 +18,13 @@ struct vgein_ctrl { /* The least-significant bits are implemented first, apart from bit 0 = */ unsigned long bmp; spinlock_t lock; + /* + * Guest interrupt file IDs run from 1 to geilen inclusive (0 means th= at + * no guest external interrupt source is selected), and geilen can nev= er + * exceed BITS_PER_LONG - 1, so indexing this array by the ID directly + * always fits. + */ + struct vcpu *owners[BITS_PER_LONG]; unsigned int geilen; }; =20 @@ -62,23 +69,25 @@ static int cf_check cpu_callback(struct notifier_block = *nfb, unsigned long action, void *hcpu) { unsigned int cpu =3D (unsigned long)hcpu; - int rc =3D 0; =20 switch ( action ) { case CPU_STARTING: - rc =3D vgein_init(); + { + int rc =3D vgein_init(); + if ( rc ) printk(XENLOG_ERR "AIA: failed to init vgein for CPU%u: %d\n", cpu, rc); break; + } =20 case CPU_DYING: vgein_deinit(); break; } =20 - return notifier_from_errno(rc); + return NOTIFY_DONE; } =20 static struct notifier_block cpu_nfb =3D { @@ -138,7 +147,10 @@ unsigned int vgein_assign(struct vcpu *v) if ( vgein_id > vgein->geilen ) vgein_id =3D 0; else + { __set_bit(vgein_id, bmp); + vgein->owners[vgein_id] =3D v; + } =20 spin_unlock_irqrestore(&vgein->lock, flags); =20 @@ -161,6 +173,7 @@ void vgein_release(struct vcpu *v, unsigned int vgein_i= d, unsigned int cpu) spin_lock_irqsave(&vgein->lock, flags); if ( !__test_and_clear_bit(vgein_id, &vgein->bmp) ) ASSERT_UNREACHABLE(); + vgein->owners[vgein_id] =3D NULL; spin_unlock_irqrestore(&vgein->lock, flags); =20 #ifdef VGEIN_DEBUG @@ -168,3 +181,36 @@ void vgein_release(struct vcpu *v, unsigned int vgein_= id, unsigned int cpu) __func__, v, vgein_id, cpu, vgein->bmp); #endif } + +void hgei_interrupt(void) +{ + unsigned long hgei_mask, flags; + struct vgein_ctrl *vgein =3D &this_cpu(vgein); + + hgei_mask =3D csr_read(CSR_HGEIP) & csr_read(CSR_HGEIE); + csr_clear(CSR_HGEIE, hgei_mask); + + spin_lock_irqsave(&vgein->lock, flags); + + for_each_set_bit ( guest_file_id, hgei_mask ) + { + /* + * guest_file_id shouldn't be zero, as it will indicate that no + * guest external interrupt source is selected for VS-level extern= al + * interrupts. + */ + ASSERT(guest_file_id); + + if ( vgein->owners[guest_file_id] ) + { +#ifdef VGEIN_DEBUG + gprintk(XENLOG_DEBUG, "%s: kick ->%pv, hgei_mask(%#lx)\n", + __func__, vgein->owners[guest_file_id], hgei_mask); +#endif + + vcpu_kick(vgein->owners[guest_file_id]); + } + } + + spin_unlock_irqrestore(&vgein->lock, flags); +} diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index 2dfe4c2e72ce..29181968224c 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -136,6 +136,8 @@ static void vcpu_csr_init(struct vcpu *v) v->arch.hstateen0 =3D (hstateen0 & csr_masks.hstateen0) | csr_masks.ro_one.hstateen0; } + + v->arch.hie =3D MIP_SGEIP; } =20 static void continue_new_vcpu(struct vcpu *prev) @@ -398,6 +400,7 @@ static void restore_csr_regs(struct vcpu *vcpu) csr_write(CSR_HEDELEG, vcpu->arch.hedeleg); csr_write(CSR_HIDELEG, vcpu->arch.hideleg); csr_write(CSR_HVIP, vcpu->arch.hvip); + csr_write(CSR_HIE, vcpu->arch.hie); csr_write64(CSR_HENVCFG, vcpu->arch.henvcfg); csr_write(CSR_HCOUNTEREN, vcpu->arch.hcounteren); csr_write64(CSR_HTIMEDELTA, vcpu->arch.htimedelta); diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c index d7b137a1f559..07152066116a 100644 --- a/xen/arch/riscv/imsic.c +++ b/xen/arch/riscv/imsic.c @@ -510,12 +510,31 @@ void cf_check imsic_ctxt_switch_from(struct vcpu *v) =20 write_lock_irqsave(&imsic_state->vsfile_lock, flags); imsic_state->vsfile_cpu =3D v->processor; + /* + * Start to observe the VS-file from HS-mode: while the vCPU isn't + * running an interrupt pending in its VS-file is reported through HGE= IP + * instead of being delivered to VS-mode, which lets Xen wake the vCPU= up. + */ + csr_set(CSR_HGEIE, BIT(imsic_state->guest_file_id, UL)); write_unlock_irqrestore(&imsic_state->vsfile_lock, flags); } =20 void cf_check imsic_ctxt_switch_to(struct vcpu *v) { - /* Nothing to do */ + struct vimsic_state *imsic_state =3D v->arch.vimsic_state; + unsigned long flags; + + /* A s/w VS-file is never observed through HGEIP. */ + if ( !vcpu_guest_file_id(v) ) + return; + + /* + * The vCPU is about to run, so hstatus.VGEIN delivers the VS-file's + * interrupts to it directly and there is nothing left for Xen to obse= rve. + */ + read_lock_irqsave(&imsic_state->vsfile_lock, flags); + csr_clear(CSR_HGEIE, BIT(imsic_state->guest_file_id, UL)); + read_unlock_irqrestore(&imsic_state->vsfile_lock, flags); } =20 int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id) @@ -646,6 +665,12 @@ static void cf_check imsic_vsfile_local_read_clear(voi= d *data) struct imsic_mrif *mrif =3D idata->mrif; unsigned long new_hstatus, old_hstatus, old_vsiselect; =20 + /* + * The HGEIE bit imsic_ctxt_switch_from() armed belongs to the old own= er + * only. + */ + csr_clear(CSR_HGEIE, BIT(idata->hgei, UL)); + old_vsiselect =3D csr_read(CSR_VSISELECT); old_hstatus =3D csr_read(CSR_HSTATUS); new_hstatus =3D old_hstatus & ~HSTATUS_VGEIN; @@ -991,6 +1016,21 @@ int __init vimsic_make_domu_dt_node(struct kernel_inf= o *kinfo, return fdt_end_node(fdt); } =20 +/* + * Start to observe the interrupt file from HS-mode, the same way + * imsic_ctxt_switch_from() does it for a vCPU which is switched out. + * + * The counterpart, clearing the bit of the interrupt file which is left + * behind, is done by imsic_vsfile_local_read_clear(), which already runs = on + * the pCPU owning that file. + */ +static void cf_check imsic_local_hgeie_set(void *data) +{ + const struct imsic_vsfile_data *idata =3D data; + + csr_set(CSR_HGEIE, BIT(idata->hgei, UL)); +} + static void cf_check imsic_vsfile_local_update(void *data) { unsigned int i; @@ -1144,6 +1184,19 @@ void imsic_migrate_vcpu(struct vcpu *v) vsfile_data.mrif =3D &tmrif; imsic_call_on_cpu(new_vsfile_cpu, imsic_vsfile_local_update, &vsfile_d= ata); =20 + /* + * A vCPU which isn't going to run right away (a cpupool move, or a + * migration of a vCPU which isn't runnable) is never switched in, so + * nobody would arm HGEIE for the new interrupt file and the state just + * restored into it would stay invisible to Xen until the vCPU is swit= ched + * out the next time, losing the wake up it is meant to cause. + * + * For a vCPU which is about to run imsic_ctxt_switch_to() clears the = bit + * anyway, as interrupts are then delivered to the vCPU directly. + */ + if ( !v->is_running ) + imsic_call_on_cpu(new_vsfile_cpu, imsic_local_hgeie_set, &vsfile_d= ata); + /* Set VCPU HSTATUS.VGEIN to new IMSIC VS-file */ vcpu_guest_cpu_user_regs(v)->hstatus &=3D ~HSTATUS_VGEIN; vcpu_guest_cpu_user_regs(v)->hstatus |=3D diff --git a/xen/arch/riscv/include/asm/aia.h b/xen/arch/riscv/include/asm/= aia.h index 8e4eb2f6b14e..6a05bdd8c236 100644 --- a/xen/arch/riscv/include/asm/aia.h +++ b/xen/arch/riscv/include/asm/aia.h @@ -12,4 +12,6 @@ void aia_init(void); unsigned int vgein_assign(struct vcpu *v); void vgein_release(struct vcpu *v, unsigned int vgein_id, unsigned int cpu= ); =20 +void hgei_interrupt(void); + #endif /* RISCV_AIA_H */ diff --git a/xen/arch/riscv/include/asm/domain.h b/xen/arch/riscv/include/a= sm/domain.h index 23e301782068..6d5eafdf5522 100644 --- a/xen/arch/riscv/include/asm/domain.h +++ b/xen/arch/riscv/include/asm/domain.h @@ -72,6 +72,7 @@ struct arch_vcpu { register_t hvip; uint64_t hviprio1; uint64_t hviprio2; + register_t hie; =20 register_t vsatp; register_t vscause; diff --git a/xen/arch/riscv/traps.c b/xen/arch/riscv/traps.c index f5f83fce10ba..b08cf2ff2e31 100644 --- a/xen/arch/riscv/traps.c +++ b/xen/arch/riscv/traps.c @@ -12,9 +12,10 @@ #include #include =20 -#include +#include #include #include +#include #include #include #include @@ -273,6 +274,10 @@ void do_trap(struct cpu_user_regs *cpu_regs) timer_interrupt(); break; =20 + case IRQ_S_GEXT: + hgei_interrupt(); + break; + default: intr_handled =3D false; break; --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844191; cv=none; d=zohomail.com; s=zohoarc; b=AhO+7cnHGvq5xk+qi2KY/QCv8cjw2+VIUIVfXNzcNBMQHEZEA8tCg4KLol2RjZk3TQr3/mJuk3l4uSFTuL98aZdsQQZmp5q7is+mePbrL1ksZWImro6FYeZPZ4dHMh6+4ox40AGLbUsVV7U4E6A+EjM5FaUDGJ1Kzj7IZqbXMD4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844191; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=DZrX2Pb+r3SHWFYfjsZtgvvx6Uq4NGHBKz3VgjDsiVc=; b=l6QE+I7yTz+ELborgFKxjOAkSuwGGDYZZTattv1IqiQ7L686HQd/DMGcjuEuIfteeVUfEQZSH7dDNwSp+cvz5V08NHk0JrjUpwAtixdh3ht76DYiSvN3PeGS9HFxmI+Oqxj12WPRzNbaSIGAjMLFIxi8PmTKgtOswwzInA+ZD9A= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844191745333.80543666834603; Thu, 27 Aug 2026 08:23:11 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1401029.1636853 (Exim 4.92) (envelope-from ) id 1wzbwK-0002J0-Rd; Thu, 27 Aug 2026 15:22:52 +0000 Received: by outflank-mailman (output) from mailman id 1401029.1636853; Thu, 27 Aug 2026 15:22:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbwJ-00025F-30; Thu, 27 Aug 2026 15:22:51 +0000 Received: by outflank-mailman (input) for mailman id 1401029; Thu, 27 Aug 2026 15:22:38 +0000 Received: from mx.expurgate.net ([194.145.224.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbw4-0007YK-Od for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:36 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbw4-009l5h-3H for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:36 +0200 Received: from [10.42.69.2] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a905633-8faa-0a2a0a5109dd-0a2a450293fc-26 for ; Thu, 27 Aug 2026 17:22:36 +0200 Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com) by tlsNG-720697.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a90563b-6ca4-0a2a45020019-d1558036b975-3 for ; Thu, 27 Aug 2026 17:22:36 +0200 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-499b2981a7bso9947135e9.3 for ; Thu, 27 Aug 2026 08:22:36 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:35 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844155; x=1788448955; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=DZrX2Pb+r3SHWFYfjsZtgvvx6Uq4NGHBKz3VgjDsiVc=; b=F++B4BFbDxnuzZqTL7Kat9glKzcL7JYnTXve5zLWlFwpjGEVxna4sWBVV7AuR6pXtB 3eAiep/cMiMywhUK6hMHjtvuNSIsnGOKHmczHpiK9jWTxJJcVVSWoZ8RSdn5HRQEo0tt cYGpEUeA5rcB1ry8qsn9E+tmoc1J5eNJnVJP8tpKJfZeeWn3/jgNERxGvnl++TsyX72h a0aAHf/RO2zfNRKXgBMLK6QHznPY7ey6wXmaB1V+9TdTRLzFfL6XcLO17TD3TkS4uTDm bk5xmFlhpwqnUdJf7BbKxO5SJw8sISxI8H2K9Bu8nTRGritRuNJki3HswAZ+1EBQAAh9 dD5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844155; x=1788448955; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=DZrX2Pb+r3SHWFYfjsZtgvvx6Uq4NGHBKz3VgjDsiVc=; b=V2AFvDlaNwdPS/4tuZGnVJUE20ePITL+7vuY5s+7eqqmnzuZ0HiWLAxw3EyhDxQ6ZW isw5UF7Ek2OKhImzalqjQu/P3wftzPVBgD1I8uYmFoG5s95vtLoBp65+mtVLdxeazZu8 2iUwTohZ2SiuiNkft0DL9CuvF1ISd7BogXxv4OXbso7vYfLlfsz9cw0rSUkbGOvU2b5R Jt8qsv3Uq/VjkE97RGOPQE6j7R/uy9h1FcsTkt5rYKD9E9tXZ8Zo54xVb5XaFHqu5g9I V1XXIU00HdjE+LEkv6xlm0Z1jgg4ypuuYr3DiZVfnmkRzhkf/5EVHxD1C73IqSQQEhT0 aziQ== X-Gm-Message-State: AFuF++mrcFajZGKK7UOr/RtK2R02m5CJn0CBqTy13wQv6v1b3IV4Yrtm 0rknHgpwo/BEytlkp8sd2CmcPQxdaVhkR3fnot0R+Ksmx/x9QkEYUG9ypUdIhg== X-Gm-Gg: AR+sD11g3VCs/MIOWBktTR01um4QAFFekocKJao5yKk/AnKs2O8fPCRcvlm4+uh+Wc+ REl2TggI/M6mfpD2+I4sdys9yGNl/9JrG7lHOKrXzYiS37BVVXXQDDaGodj2DRz/w43FVSRchrJ 6LLwH1sL/a0/98TFtF8UH4D+K9QLZuEhGC+iT8LLGFqdsAu7SvXa+hJQcQ3opEA8T4y1V3cN8N7 7CLxhY+PPw9CjaFmqB4qRERnIg/rpDJ4/9Ukc9h4bsqBCQE6nrWsIo9oBFEliKr3vSqggN3ccUe ccFCueytFxqH6L/Nlz9LnFZ55FecxPQS7VfLuXCqEc40KfeLlPDrFKH9zvsaL2U06osJvl4uNeY RJax+yBXNBd8f6bdLGmFnMlHtNYLwHGexNCEc8FCYRNbagH2ySQ5vmnQSEFVOUebemLh1lxPxR1 A7P7bhvt6X3YBXdrc72ab4Hyb08qMf50h7vChAswRr5KHSjtdOFuM+LG5hWHEVQkGWt/ospYOZU EhqcpREwLFdjzjCJdgLXJXulB3vk8c3 X-Received: by 2002:a05:600c:3baa:b0:499:ae94:be05 with SMTP id 5b1f17b1804b1-499dc6a3e86mr223264115e9.0.1787844155307; Thu, 27 Aug 2026 08:22:35 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 37/39] xen/riscv: map IMSIC interrupt file for vCPUs Date: Thu, 27 Aug 2026 17:21:21 +0200 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-720697/1787844156-F24B62AC-B68AF592/10/73395122804 X-purgate-type: spam X-purgate-size: 5116 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844192592158500 Content-Type: text/plain; charset="utf-8" A guest running in VS-mode expects its own IMSIC S-file at offset 0 of its guest-physical IMSIC block. Physically, the guest-file (G-file) assigned to this vCPU lives at a hart-relative offset given by guest_file_id (assigned via the vGEIN allocator). Therefore, imsic_map_guest_file() uses stage-2 translation to redirect the guest's fixed per-vCPU GPA page (offset 0) to the specific physical guest-file page. Signed-off-by: Oleksii Kurochko --- Changes in v2: - Use GUEST_IMSIC_S_BASE instead of imsic_cfg.base_addr as the base of the guest address to map to, and change the type of gaddr to paddr_t as it holds a guest physical address. - Rename guest_stride to guest_offset: it is an offset of the VS-file insi= de the pCPU's IMSIC block, not a stride. - Use PRIpaddr for physical addresses and %u for unsigned values in the debug/error messages. - Switch the mapping failure message from printk() to dprintk(XENLOG_ERR, = ...). - Update the comment above imsic_map_guest_file(): vCPUs aren't pinned, th= ey run on the pCPU chosen by the scheduler, and mention that on migration a VS-file is acquired on the new pCPU and mapped at the same GFN, so the stale mapping is replaced rather than explicitly torn down. --- --- xen/arch/riscv/imsic.c | 66 +++++++++++++++++++++++++++++++++++++++++- 1 file changed, 65 insertions(+), 1 deletion(-) diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c index 07152066116a..374a21ace15f 100644 --- a/xen/arch/riscv/imsic.c +++ b/xen/arch/riscv/imsic.c @@ -29,6 +29,7 @@ #include #include #include +#include =20 #define IMSIC_HART_SIZE(guest_bits) (BIT(guest_bits, U) * IMSIC_MMIO_PAGE_= SZ) =20 @@ -537,9 +538,72 @@ void cf_check imsic_ctxt_switch_to(struct vcpu *v) read_unlock_irqrestore(&imsic_state->vsfile_lock, flags); } =20 +/* + * Map the physical IMSIC guest interrupt file (G-file) assigned to vCPU + * into the domain's stage-2 guest-physical address space. + * + * In the machine's physical address space (SPA), each hart's IMSIC + * supervisor-level file (S-file) is located at offset 0 of its address bl= ock, + * followed contiguously by GEILEN guest files at offsets of 1, 2, ..., N = pages. + * + * Because a guest OS running in VS-mode expects its own supervisor-level + * interrupt file to be at offset 0 of its guest-physical IMSIC block, the + * hypervisor must use stage-2 address translation to map the vCPU's + * guest-physical "supervisor" page (GPA offset 0) to the specific + * physical guest file page (SPA offset guest_file_id) on the physical har= t. + * + * A vCPU runs on the pCPU the scheduler picked for it (v->processor), and + * the guest file it is given (guest_file_id, from the vGEIN allocator) + * belongs to that very pCPU's IMSIC. A guest_file_id of 0 indicates that = no + * hardware guest file is selected (matching the architectural behavior wh= ere + * vGEIN =3D 0 in the hstatus CSR selects no guest external interrupt sour= ce), + * requiring the VS-file to be emulated in software. + * + * Consequently the mapping installed here is only valid as long as the vC= PU + * stays on that pCPU. When it migrates, a VS-file is acquired on the new + * pCPU and mapped at the very same GFN, so the stale mapping needs no + * explicit tear-down: it is simply replaced. + * + * The base guest-physical address advertised to the guest in the device + * tree matches offset 0 of the vCPU's virtual IMSIC block. Stage-2 + * translation ensures that guest supervisor accesses to this page are + * transparently routed to the real hardware VS-file granted to it on + * the pCPU it currently runs on. + */ int imsic_map_guest_file(struct vcpu *v, unsigned int vsfile_id) { - return -EOPNOTSUPP; + struct domain *d =3D v->domain; + unsigned int cpu =3D v->processor; + paddr_t gaddr =3D GUEST_IMSIC_S_BASE + (IMSIC_MMIO_PAGE_SZ * v->vcpu_i= d); + paddr_t paddr, guest_offset; + int res; + + /* Nothing to map in the case of sw interrupt file. */ + if ( !vsfile_id ) + return 0; + + guest_offset =3D vsfile_id * IMSIC_MMIO_PAGE_SZ; + + paddr =3D imsic_cfg.msi[cpu].base_addr + imsic_cfg.msi[cpu].offset + + guest_offset; + +#ifdef IMSIC_DEBUG + printk(XENLOG_DEBUG + "%s: %pv: ga(%#"PRIpaddr") -> pa(%#"PRIpaddr"), cpu(%u), " + "guest_file_id(%u) base_addr(%#"PRIpaddr") offset(%#lx)\n", + __func__, v, gaddr, paddr, cpu, vsfile_id, + imsic_cfg.msi[cpu].base_addr, imsic_cfg.msi[cpu].offset); +#endif + + res =3D map_regions_p2mt(d, gaddr_to_gfn(gaddr), + PFN_DOWN(IMSIC_MMIO_PAGE_SZ), maddr_to_mfn(padd= r), + arch_dt_passthrough_p2m_type()); + if ( res ) + dprintk(XENLOG_ERR, + "%s: Failed to map %#"PRIpaddr" to the guest at %#"PRIpadd= r"\n", + __func__, paddr, gaddr); + + return res; } =20 int cf_check vcpu_imsic_init(struct vcpu *v) --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844193; cv=none; d=zohomail.com; s=zohoarc; b=W6w5BDZ82gkF6Pws3x0Yspr3HL5RQ3AwESplpyJpHJ3xf2TVbu2/+iKuu5vGf16Onj6vohfxwEqUpZQkArhqLMM9XzWQofm8CFUOGSjWJk9w+i78zw77eeP9oHRMUTm2kTgQGWQ/gSbhyc3UuCE1jbBBvW33YxhajDeu+wF7flg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844193; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=6FUxAqwWcnc2Ay1jeD5JiD2529ILkdTEuy10fqJCXM0=; b=N1rc/whBESKFWh69BEM6VdyqGUOU+12Qikfqxs2SInxhh6h0cEjB/cTRqqVBrNMnyozE5EBpizE0ie9/3p59QJHT3TId2zpc3UJgoW4xbqWsELSFHEZQmWk+5gBEVdODnlfj644hATYPeU/dKRKWYYJl3M494abSJ0YrdhZCRXo= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844193438780.0631144877198; Thu, 27 Aug 2026 08:23:13 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1401032.1636858 (Exim 4.92) (envelope-from ) id 1wzbwL-0002Xp-Ng; Thu, 27 Aug 2026 15:22:53 +0000 Received: by outflank-mailman (output) from mailman id 1401032.1636858; Thu, 27 Aug 2026 15:22:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbwK-0002Su-Ic; Thu, 27 Aug 2026 15:22:52 +0000 Received: by outflank-mailman (input) for mailman id 1401032; Thu, 27 Aug 2026 15:22:39 +0000 Received: from mx.expurgate.net ([195.190.135.20]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbw5-0007lh-Ti for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:38 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbw5-003O3L-8V for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:37 +0200 Received: from [10.42.69.1] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a905626-e002-0a2a0a5209dd-0a2a4501aa5e-32 for ; Thu, 27 Aug 2026 17:22:37 +0200 Received: from [209.85.128.54] (helo=mail-wm1-f54.google.com) by tlsNG-d62444.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a90563d-5984-0a2a45010019-d1558036f024-3 for ; Thu, 27 Aug 2026 17:22:37 +0200 Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-4953e04ef16so22305995e9.2 for ; Thu, 27 Aug 2026 08:22:37 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:36 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844157; x=1788448957; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=6FUxAqwWcnc2Ay1jeD5JiD2529ILkdTEuy10fqJCXM0=; b=YdFjGfQmXz5SJHxaKpa05ARMIRGvgNBHC+UZpLe/KYBqzhahptWwMGm9uM/ZvL2R1f ebiaPVUiVmn08nnpAZOzBJYby1IfhBNXJ+axoqbWtEWPLiKZXYzTmZmKQKHcVRVADmYR XlsUiD3zBmSH726JK5oCJtwEJUEpUHaY4KpswrhOvd4xtJDIMVlsfhNq1wHHeoNS+1Wh dJK4w0a0a0/E3+XxW9hrOTLUxgx3/dYFAP6yebMlkXmOsl0cXsGOJcZT4mSH1qcSRP0E GX2bmiFx6Vp7BVvxqZvyblZvE3KQrVdfsIBlNE3R0kK6T3JKlosNcsxtQmx+GpxS9G8w sz+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844157; x=1788448957; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=6FUxAqwWcnc2Ay1jeD5JiD2529ILkdTEuy10fqJCXM0=; b=eoporww5xRhKBQE2klxuceTpAFebzhhuEvjflsnyazs73a1OgS9yh70dy8fEvYE3/s qF6h9fnEx6PM3H1l+DuVLBqLzGMBdw0G22tfK9/RkatI+6MmJmOaX4XBkeXFPwLT76pE IR1f/4vhMZ0BAZeJG/h/72lVo/XQfN7yUJzhMRqeDAtM4M3BBSF/+hL5ThrT2t8GtW3Z Frouk8aJ+NjWNr5QRutdPDPBnW9TUTlQIYUXNJ+CwCRcJKJ9540tQXIXmcTce0qxuoW/ lqeGhUcp8CpNgRX27c4ceP3AwRiBQStVrfYUlFoZsvGJE+6cUbuxAtFlmuBw2mScOHzI wVXQ== X-Gm-Message-State: AFuF++mf/dCu+PaJ9hymzrUW4Ns93cHJhaiy220GAPxlshKJge5gqaPS Y9uMVUnVr7AhZfP6PkKkqbZNvODr+bebcxhNFbRcuEmCXYYWrUU2wwgPtxxHsQ== X-Gm-Gg: AR+sD11jqA/TnlvFhTytKlClmoqWn/QFQlphtp9VugXcUexAkJsPfqzz5zQlvIbVhtZ +ax3nXIP3LMJl+aFRilrCt44UMT0N5F+5gwdXnZTOzRIrmDw8crGeu9LHu/lYlxd++pDG3kVqlt 4K6JSdxCl2VfL/jHhbxJLKYaFW94R1Hk3n7knZh59BnuSv6dAQLTfeHqyXFW36dWCX/9Oq+F1hO /eyw0+k1db185o3A5qcMz/og2UOCNGGp9g6gFIdecWvgUh111OY6Gn6zDF5mFWosk87e8zOkHyO Tc0XKs2k03BKk9vhA7Oyholr+MSLrAN+PZkX11lbMyFqJv/DHYOE2X7jZ5EAARyYHliA9RCW0L1 X/gtyoBnjJN2s2QUR25YCvyyOlDq49DizVRVZpJ0vb8y4lEYuGL0Ugu5GGiIgTfDKQDUGboArOI pydfqUI+7A5Q/p38KITO8wIwRw7tQEwH42Ea08Zc4f+s/vH/lHJgMTVJOi9PC16GkmogAoR8wJA gNSaGPMKhvkiQvNwJVoRJZy4kTSiIfW X-Received: by 2002:a05:600c:3144:b0:499:79b9:e220 with SMTP id 5b1f17b1804b1-499dc72548dmr187765125e9.10.1787844156618; Thu, 27 Aug 2026 08:22:36 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 38/39] xen/riscv: implement continue_new_vcpu() Date: Thu, 27 Aug 2026 17:21:22 +0200 Message-ID: X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-d62444/1787844157-BE664757-AFC1CA69/10/73395122804 X-purgate-type: spam X-purgate-size: 6071 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844194605158500 Content-Type: text/plain; charset="utf-8" continue_new_vcpu() is the arch hook invoked the first time a freshly created vCPU is scheduled. Implement both cases it has to cover: - for the idle vCPU, switch to its own stack and jump to idle_loop(); - for a guest vCPU, restore hstatus and enter the guest through the new return_to_new_vcpu() path in entry.S, which loads sepc, passes the hart id in a0 and the DTB address in a1 as expected by the RISC-V boot protocol, sets sstatus.SPP and executes sret. Interrupts have to stay disabled across the restore. The trap entry logic implicitly clears hstatus.SPV, so an interrupt taken between the write of hstatus and sret would make sret return to HS-mode instead of VS-mode, and restoring SPV afterwards is non-trivial. Instead interrupts are simply kept off and sstatus.SPIE is set, so that SIE is restored from SPIE once sret has been executed. Also, it follows what hardware will do with real CPU which is also started with interrupts disabled. Introduce get_cpu_info() and reset_stack_and_jump() in asm/current.h, needed by the above. get_cpu_info() is a macro rather than a static inline because asm/current.h is pulled in by before this_cpu() is defined and before completes struct vcpu. idle_loop() is added as a stub on purpose; its real implementation will come separately later. Signed-off-by: Oleksii Kurochko --- Changes in v2: - New patch. --- --- xen/arch/riscv/domain.c | 44 +++++++++++++++++++++++++++- xen/arch/riscv/entry.S | 23 +++++++++++++++ xen/arch/riscv/include/asm/current.h | 4 +++ 3 files changed, 70 insertions(+), 1 deletion(-) diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index 29181968224c..0782148b7207 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -8,10 +8,13 @@ #include #include =20 +#include +#include #include #include #include #include +#include #include #include #include @@ -140,9 +143,43 @@ static void vcpu_csr_init(struct vcpu *v) v->arch.hie =3D MIP_SGEIP; } =20 +static void schedule_tail(struct vcpu *prev); +static void noreturn idle_loop(void); +void noreturn return_to_new_vcpu(void); + static void continue_new_vcpu(struct vcpu *prev) { - BUG_ON("unimplemented\n"); + schedule_tail(prev); + + if ( is_idle_vcpu(current) ) + reset_stack_and_jump(idle_loop); + else + { + /* + * During a context switch to a new vCPU, interrupts must be disab= led + * to guarantee that the vCPU's CSR state can be safely restored i= nto + * the hart without being clobbered by an interrupt trap. + * + * For example, when return_to_new_vcpu() finishes, it executes sr= et. + * At that point, the hart checks hstatus.SPV=3D1 and sstatus.SPP= =3D1 in + * order to return from HS-mode into VS-mode. If an interrupt were= to + * arrive before sret, the trap entry logic would implicitly clear + * hstatus.SPV to 0. Correctly restoring it afterwards is non-triv= ial, + * and if left as 0, sret would incorrectly return to HS-mode inst= ead + * of VS-mode. + * + * To avoid this, interrupts are kept disabled during the restore. + * Additionally, setting sstatus.SPIE=3D1 ensures that after sret = is + * executed (as sstatus.SIE will be loaded from SPIE), HS-mode will + * continue to receive interrupts normally. + */ + local_irq_disable(); + csr_set(CSR_SSTATUS, SSTATUS_SPIE); + + csr_write(CSR_HSTATUS, vcpu_guest_cpu_user_regs(current)->hstatus); + + reset_stack_and_jump(return_to_new_vcpu); + } } =20 int arch_vcpu_create(struct vcpu *v) @@ -551,3 +588,8 @@ static void __init __maybe_unused build_assertions(void) */ BUILD_BUG_ON(offsetof(struct cpu_info, guest_cpu_user_regs)); } + +static void noreturn idle_loop(void) +{ + BUG_ON("unimplemented"); +} diff --git a/xen/arch/riscv/entry.S b/xen/arch/riscv/entry.S index 331446a238d3..bf1843dcea4f 100644 --- a/xen/arch/riscv/entry.S +++ b/xen/arch/riscv/entry.S @@ -143,3 +143,26 @@ FUNC(__context_switch) =20 ret END(__context_switch) + +/* t0 is used as a temporary reg and is clobbered to oblivion */ +FUNC(return_to_new_vcpu) + /* Swap tp with sscratch */ + csrrw tp, CSR_SSCRATCH, tp + + /* Set vCPU registers */ + REG_L t0, CPU_USER_REGS_SEPC(sp) + csrw sepc, t0 + + /* Hartid goes to a0 */ + REG_L a0, CPU_USER_REGS_A0(sp) + + /* DTB goes to a1 */ + REG_L a1, CPU_USER_REGS_A1(sp) + + /* Set guest mode to supervisor */ + li t0, SSTATUS_SPP + csrs CSR_SSTATUS, t0 + + /* Enter guest */ + sret +END(return_to_new_vcpu) diff --git a/xen/arch/riscv/include/asm/current.h b/xen/arch/riscv/include/= asm/current.h index 78ec52fd8a35..f8babcc3d926 100644 --- a/xen/arch/riscv/include/asm/current.h +++ b/xen/arch/riscv/include/asm/current.h @@ -47,6 +47,8 @@ DECLARE_PER_CPU(struct vcpu *, curr_vcpu); #define set_current(vcpu) do { current =3D (vcpu); } while (0) #define get_cpu_current(cpu) per_cpu(curr_vcpu, cpu) =20 +#define get_cpu_info() (current->arch.cpu_info) + #define guest_cpu_user_regs() ({ BUG_ON("unimplemented"); NULL; }) #define vcpu_guest_cpu_user_regs(vcpu) \ (&(vcpu)->arch.cpu_info->guest_cpu_user_regs) @@ -58,6 +60,8 @@ DECLARE_PER_CPU(struct vcpu *, curr_vcpu); unreachable(); \ } while ( false ) =20 +#define reset_stack_and_jump(fn) switch_stack_and_jump(get_cpu_info(), fn) + #define get_per_cpu_offset() __per_cpu_offset[smp_processor_id()] =20 #endif /* __ASSEMBLER__ */ --=20 2.55.0 From nobody Thu Sep 3 07:03:20 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=none dis=none) header.from=gmail.com ARC-Seal: i=1; a=rsa-sha256; t=1787844194; cv=none; d=zohomail.com; s=zohoarc; b=BzkOE5An4nyL1UKjdOIzYSmENoxzJx+LZGPMw0VnHDIlrzaXk7hXz6b7WrjfeRYEXW5IwWJYDV6wF6JsRH3iEd3lEvq7nnOFHNW9QnE3E92iVODhhp1dsm03Hu4pH9QW9NXsEhxolFrcgeRPx30R+KwWtCZA+b23H1f5z7c30pw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1787844194; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=ectEPOeVMacpPQ0PahqNUgVXssdptDzQr1HvL6IKR+M=; b=bZFytJ5PTSkI8VP4srl8v4xAwEfJo01UsYIlpFsA+8yW8IJZK1tSL7bD2diVvgDqnf/vdI7P5J2Uh9868puaDwKLCeLm32mFEqrAo/ycsk/9SJNUD3W/moCCwuu5r7rQADexrGi6a5SuGA+HSmmGyz2FTsyRnO75sZ0dEEFrf/U= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1787844194027923.3494485363574; Thu, 27 Aug 2026 08:23:14 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.1401034.1636866 (Exim 4.92) (envelope-from ) id 1wzbwO-0002x1-5p; Thu, 27 Aug 2026 15:22:56 +0000 Received: by outflank-mailman (output) from mailman id 1401034.1636866; Thu, 27 Aug 2026 15:22:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1wzbwM-0002q2-Nn; Thu, 27 Aug 2026 15:22:54 +0000 Received: by outflank-mailman (input) for mailman id 1401034; Thu, 27 Aug 2026 15:22:40 +0000 Received: from mx.expurgate.net ([195.190.135.10]) by lists.xenproject.org with esmtp (Exim 4.92) id 1wzbw7-00084E-DC for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 15:22:39 +0000 Received: from mx.expurgate.net (helo=localhost) by mx.expurgate.net with esmtp id 1wzbw6-00GwJA-P4 for xen-devel@lists.xenproject.org; Thu, 27 Aug 2026 17:22:38 +0200 Received: from [10.42.69.7] (helo=localhost) by localhost with ESMTP (eXpurgate MTA 0.9.1) (envelope-from ) id 6a90563b-bab6-0a2a0a5309dd-0a2a4507d6aa-6 for ; Thu, 27 Aug 2026 17:22:38 +0200 Received: from [209.85.128.47] (helo=mail-wm1-f47.google.com) by tlsNG-ef75cf.mxtls.expurgate.net with ESMTPS (eXpurgate 4.57.1) (envelope-from ) id 6a90563e-b4ea-0a2a45070019-d155802fe169-3 for ; Thu, 27 Aug 2026 17:22:38 +0200 Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-49554ebb87dso21865525e9.3 for ; Thu, 27 Aug 2026 08:22:38 -0700 (PDT) Received: from fedora (user-109-243-144-234.play-internet.pl. [109.243.144.234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49b4b2d6b30sm57441155e9.14.2026.08.27.08.22.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 27 Aug 2026 08:22:37 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Authentication-Results: eu.smtp.expurgate.cloud; dkim=pass header.s=20251104 header.d=gmail.com header.i="@gmail.com" header.h="Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1787844158; x=1788448958; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=ectEPOeVMacpPQ0PahqNUgVXssdptDzQr1HvL6IKR+M=; b=Ot+G2rScBjlquD70Hjnbz6Whkebbq9oaCxDsmguGYYJCL6cEgWyku9DLlDbep2EbpE kJnvnCuEyh565YoDpyfy7nv78KyT/5d6dRNhGST9Hx5GNG35AlgGJ9EPEFdoynh//DuT MRsnYg9V3+vnpnA/Q0xTMR7sH3loqNQRSv9BCM+6UsTUCgiG/aX1skp7BkNifnVpW8vf PuWmAU/PIDe70YhMILsBQjgy+D4P2WxXFMxcHdzF0r8rXyM+9sVXiwCEwJptVLRH+Utm T7Tsb+PZzLuhHV/4xA/zId5OlAFMQl6/eLt3+YhTzmcgE4NkgNaHbCjrlsQO6prUsj2j Cp7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787844158; x=1788448958; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=ectEPOeVMacpPQ0PahqNUgVXssdptDzQr1HvL6IKR+M=; b=Mbe3JlHAjiTrc06wbHE9pw929tOGHBMh3yrrYBf/2+tdLP3MmfclAf5N+OLcuKaKS+ 3h5YMbl814arkWIsk5ZjhAu19fMr4BzOjvSC+g0+TrETt8+g7ILHZc23OC3c0xOBKm9R YWmkQhhpX90KQ6dWWRq8AlhCrUJea5MzhnmcH8T9HQj5mFCBAa2/jdHb2Wr77cdEgoUf 9fI5Nr/2BDSLwXwZ4gy+1ki3EJ+/U0+WFVIJn/0onz5ME/BdxwgDIaQ+JGTtGetS/f8G jd6yCFUBUCe7VA3dHNzSLlDzdekLon7Sam1gZ+xfYvr5nqSCJc+86/oL+nYSMPxxbp/u Wxmg== X-Gm-Message-State: AFuF++kExVWEa9e6YEH2PvwPR4V/pOQ+YexwustxeNhEOxS20a6x8xbF uGjasOCWQsSe8nEsMor7SKOrxsSIf1asT45QntH52qngxbDd5JpVlkWrlsUhHg== X-Gm-Gg: AR+sD11z1AdFeGUu0Hfv/wdpa/URoQmZR2NiJ8SLbhwMmFkvp3r8xlWKBLrqfvNeG+C MYUe4fRiUV72No1V07GVnTDEQiWY3muDwDZ/V8KylkZhcYcCx99aAo0a5zJ9umW8HR9zqHcpo3Q p12jlQQdXdvnSsiiyYaTHXS3SO1xaGrU8nglysdMfL41C8BL5GEmIDIvwoIc4L43fAXoGJnc4Ub d9054xyK+Qm6pcZYpxpth3AxHsu6iMI7Ykj1t7wvapNOW1e0hxzbJtZTcI9o7SqBQxIj58HTLap tMMWaHKq9p7d4bAzXDswH2higGrkqhvMSfeIKv6Kai6g93MvDZGj9B6yI2D2PmjeW23mxjI/h1R hgcaDOfZyhAL+gGep7ksSCY1Y+zW64Z2IMsQ+X8S5/HfoV5inNFSqEEGDrl/nfj9HIpSQZL14Y5 Y0j37L1+KQnAX6aJ/qfbBN0e6ifVtMGm3dB2yWIYdXTfnoro3yCdhPDjblwMTthBoKDOwc0WAMe bFPK8LgGqyg1fAYz1tFrl3ueGUxxlwKZrG0c2e/Y+M= X-Received: by 2002:a05:600c:4592:b0:499:b402:6c0 with SMTP id 5b1f17b1804b1-499dc6eac3bmr188356345e9.3.1787844158052; Thu, 27 Aug 2026 08:22:38 -0700 (PDT) From: Oleksii Kurochko To: xen-devel@lists.xenproject.org Cc: Romain Caritey , Baptiste Le Duc , Zheng Zhang , Oleksii Kurochko , Alistair Francis , Connor Davis , Andrew Cooper , Anthony PERARD , Michal Orzel , Jan Beulich , Julien Grall , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Stefano Stabellini Subject: [PATCH v2 39/39] xen/riscv: introduce IMSIC h/w interrupt file attaching to vcpu Date: Thu, 27 Aug 2026 17:21:23 +0200 Message-ID: <4df9cf63943d0f371c8a25c6c9e84adbd3083a61.1787838835.git.oleksii.kurochko@gmail.com> X-Mailer: git-send-email 2.55.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-purgate-ID: tlsNG-ef75cf/1787844158-360C5AE4-AB5AF2C0/10/73395122804 X-purgate-type: spam X-purgate-size: 9880 X-ZohoMail-DKIM: pass (identity @gmail.com) X-ZM-MESSAGEID: 1787844194667158501 Content-Type: text/plain; charset="utf-8" Introduce imsic_vsfile_attach() to initialize the AIA-related state needed for a vCPU to have a working guest interrupt file. A guest (VS) interrupt file must be mapped to one of a pCPU's hardware interrupt files (if they exist), so the pCPU a vCPU will actually run on needs to be known first. arch_vcpu_create() is therefore not a suitable place to call vcpu_aia_init(), since the pCPU assigned to a vCPU can still change before it is first scheduled. To avoid reassigning the VS interrupt file id and remapping it to a different pCPU's hardware interrupt file, imsic_vsfile_attach() is called from a later point in the scheduling path (e.g. continue_new_vcpu()). Since it will end up being called from a non-__init context, it is not itself marked __init. Introduce imsic_update_state() to update a vCPU's guest IMSIC state (the guest interrupt file id and the pCPU whose hardware interrupt file it is mapped to) as a single consistent unit. This state can be read concurrently, e.g. by a future helper that checks whether a vCPU has a pending IMSIC interrupt, though no such consumer exists yet at this stage, so it is protected by a lock. Signed-off-by: Oleksii Kurochko --- Changes in v2: - Update vcpu_aia_init() to catch sw interrupt file and update some debug messages in it. - Add vgein_release() if IMSIC h/w mapping failed. - imsic_update_state(): store v->processor rather than cpuid_to_hartid(), as ->vsfile_cpu is consumed as a Xen CPU id (aplic_hart_field(), cpumask_of()) and its NR_CPUS sentinel lives in that numbering space. - Drop parantethis aroud guest_file_id ? ... in imsic_update_state(). - Rename vcpu_aia_init to imsic_vsfile_attach() and move the code to imsic.c. --- --- xen/arch/riscv/domain.c | 2 + xen/arch/riscv/imsic.c | 146 +++++++++++++++++++++++------ xen/arch/riscv/include/asm/imsic.h | 2 + 3 files changed, 121 insertions(+), 29 deletions(-) diff --git a/xen/arch/riscv/domain.c b/xen/arch/riscv/domain.c index 0782148b7207..15b6bfffa97d 100644 --- a/xen/arch/riscv/domain.c +++ b/xen/arch/riscv/domain.c @@ -155,6 +155,8 @@ static void continue_new_vcpu(struct vcpu *prev) reset_stack_and_jump(idle_loop); else { + imsic_vsfile_attach(current); + /* * During a context switch to a new vCPU, interrupts must be disab= led * to guarantee that the vCPU's CSR state can be safely restored i= nto diff --git a/xen/arch/riscv/imsic.c b/xen/arch/riscv/imsic.c index 374a21ace15f..ad638d748517 100644 --- a/xen/arch/riscv/imsic.c +++ b/xen/arch/riscv/imsic.c @@ -212,7 +212,14 @@ unsigned int vcpu_guest_file_id(const struct vcpu *v) =20 void imsic_update_state(struct vcpu *v, unsigned int guest_file_id) { - BUG_ON("unimplemented\n"); + unsigned long flags; + struct vimsic_state *vimsic_state =3D v->arch.vimsic_state; + unsigned int cpu =3D guest_file_id ? v->processor : NR_CPUS; + + write_lock_irqsave(&vimsic_state->vsfile_lock, flags); + vimsic_state->guest_file_id =3D guest_file_id; + vimsic_state->vsfile_cpu =3D cpu; + write_unlock_irqrestore(&vimsic_state->vsfile_lock, flags); } =20 void __init imsic_ids_local_delivery(bool enable) @@ -640,6 +647,16 @@ struct imsic_vsfile_data { struct imsic_mrif *mrif; }; =20 +/* + * Number of 64-bit EIx groups needed to cover all the interrupt identitie= s an + * IMSIC interrupt file provides, which are 0 (never valid, but it still + * occupies a bit) up to and including imsic_cfg.nr_ids. + */ +static unsigned int imsic_nr_eix(void) +{ + return DIV_ROUND_UP(imsic_cfg.nr_ids + 1, BITS_PER_TYPE(uint64_t)); +} + /* * Execute func() on the pCPU which owns the IMSIC interrupt file func() is * going to work with. @@ -1138,20 +1155,90 @@ static void cf_check imsic_vsfile_local_update(void= *data) csr_write(CSR_VSISELECT, old_vsiselect); } =20 +/* + * Point the vCPU's HSTATUS.VGEIN at the guest interrupt file it has been + * given. It is applied to the hart when the vCPU's context is restored. + */ +static void vcpu_set_vgein(struct vcpu *v, unsigned int vsfile_id) +{ + unsigned long hstatus =3D vcpu_guest_cpu_user_regs(v)->hstatus; + + hstatus &=3D ~HSTATUS_VGEIN; + hstatus |=3D MASK_INSR(vsfile_id, HSTATUS_VGEIN); + + vcpu_guest_cpu_user_regs(v)->hstatus =3D hstatus; +} + +/* + * Take a h/w guest interrupt file of 'cpu' for the vCPU: zero the file ou= t, + * map it into the domain's G-stage at the vCPU's virtual IMSIC page and + * record the new location in the per-vCPU IMSIC state. + * + * HSTATUS.VGEIN is deliberately left alone: the vCPU may be pointed at the + * file only when the file already holds the vCPU's interrupt state, which= in + * the case of imsic_migrate_vcpu() happens only after the old file has be= en + * moved to the new one. Thereby it is up to the caller to call + * vcpu_set_vgein() at the right moment. + * + * Returns the id of the taken interrupt file, or 0 if none could be taken= , in + * which case the domain is crashed. + */ +static unsigned int imsic_vsfile_acquire(struct vcpu *v, unsigned int cpu) +{ + struct imsic_vsfile_data vsfile_data =3D { .nr_eix =3D imsic_nr_eix() = }; + unsigned int vsfile_id; + int rc; + + vsfile_id =3D vgein_assign(v); + if ( !vsfile_id ) + { + /* + * vgein_assign() returns 0 when no free h/w guest interrupt file = is + * available. s/w guest interrupt files aren't supported yet, so s= uch + * a vCPU can't be run. + */ + domain_crash(v->domain, + "%pv: no free h/w guest interrupt file on CPU%u\n", + v, cpu); + return 0; + } + + vsfile_data.hgei =3D vsfile_id; + + /* The file could still hold the state of its previous owner */ + imsic_call_on_cpu(cpu, imsic_vsfile_local_clear, &vsfile_data); + + rc =3D imsic_map_guest_file(v, vsfile_id); + if ( rc ) + { + vgein_release(v, vsfile_id, cpu); + + /* Can't continue w/o correctly mapped IMSIC interrupt file */ + domain_crash(v->domain, + "%pv: failed to map h/w guest interrupt file %u: %d\n= ", + v, vsfile_id, rc); + return 0; + } + + imsic_update_state(v, vsfile_id); + + return vsfile_id; +} + void imsic_migrate_vcpu(struct vcpu *v) { - unsigned int new_vsfile_hgei; + unsigned int new_vsfile_id; unsigned int new_vsfile_cpu; - unsigned int nr_hw_eix =3D DIV_ROUND_UP(imsic_cfg.nr_ids + 1, - BITS_PER_TYPE(uint64_t)); - struct imsic_vsfile_data vsfile_data =3D { - .nr_eix =3D nr_hw_eix, - }; + unsigned int nr_hw_eix =3D imsic_nr_eix(); struct vimsic_state *imsic_state =3D v->arch.vimsic_state; unsigned long flags; unsigned int old_vsfile_id; unsigned int old_vsfile_cpu; struct imsic_mrif tmrif =3D { }; + struct imsic_vsfile_data vsfile_data =3D { + .nr_eix =3D nr_hw_eix, + .mrif =3D &tmrif, + }; =20 /* * The scheduler can mark a freshly created vCPU's unit as migrated and @@ -1189,25 +1276,10 @@ void imsic_migrate_vcpu(struct vcpu *v) */ new_vsfile_cpu =3D v->processor; =20 - new_vsfile_hgei =3D vgein_assign(v); - - /* We don't support SW interrupt files at the moment. */ - BUG_ON(!new_vsfile_hgei); - - vsfile_data.hgei =3D new_vsfile_hgei; - - /* Zero-out new IMSIC VS-file */ - imsic_call_on_cpu(new_vsfile_cpu, imsic_vsfile_local_clear, &vsfile_da= ta); - - /* Update G-stage mapping for the new IMSIC VS-file */ - if ( imsic_map_guest_file(v, new_vsfile_hgei) ) - { - domain_crash(v->domain, "Migration to hw interrupt file failed\n"); - + /* Zero-out, map and start to use the new IMSIC VS-file */ + new_vsfile_id =3D imsic_vsfile_acquire(v, new_vsfile_cpu); + if ( !new_vsfile_id ) return; - } - - imsic_update_state(v, new_vsfile_hgei); =20 /* * TODO: Modify the relevant translation tables at all IOMMUs so that = MSIs @@ -1245,7 +1317,7 @@ void imsic_migrate_vcpu(struct vcpu *v) vgein_release(v, old_vsfile_id, old_vsfile_cpu); =20 /* Restore register state in the new IMSIC VS-file */ - vsfile_data.mrif =3D &tmrif; + vsfile_data.hgei =3D new_vsfile_id; imsic_call_on_cpu(new_vsfile_cpu, imsic_vsfile_local_update, &vsfile_d= ata); =20 /* @@ -1262,7 +1334,23 @@ void imsic_migrate_vcpu(struct vcpu *v) imsic_call_on_cpu(new_vsfile_cpu, imsic_local_hgeie_set, &vsfile_d= ata); =20 /* Set VCPU HSTATUS.VGEIN to new IMSIC VS-file */ - vcpu_guest_cpu_user_regs(v)->hstatus &=3D ~HSTATUS_VGEIN; - vcpu_guest_cpu_user_regs(v)->hstatus |=3D - MASK_INSR(new_vsfile_hgei, HSTATUS_VGEIN); + vcpu_set_vgein(v, new_vsfile_id); +} + +void imsic_vsfile_attach(struct vcpu *v) +{ + unsigned int new_vsfile_id; + + if ( !aia_usable() ) + return; + + new_vsfile_id =3D imsic_vsfile_acquire(v, v->processor); + if ( !new_vsfile_id ) + return; + + /* + * The vCPU has never run yet, so the just zeroed out file is all the + * interrupt state it has and HSTATUS.VGEIN can be pointed at it at on= ce. + */ + vcpu_set_vgein(v, new_vsfile_id); } diff --git a/xen/arch/riscv/include/asm/imsic.h b/xen/arch/riscv/include/as= m/imsic.h index 6395b539c52d..f0edf0bff5d9 100644 --- a/xen/arch/riscv/include/asm/imsic.h +++ b/xen/arch/riscv/include/asm/imsic.h @@ -125,4 +125,6 @@ int imsic_map_guest_file(struct vcpu *v, unsigned int v= sfile_id); =20 void imsic_migrate_vcpu(struct vcpu *v); =20 +void imsic_vsfile_attach(struct vcpu *v); + #endif /* ASM_RISCV_IMSIC_H */ --=20 2.55.0